Saturday, July 11, 2009

Sharepoint: Coding Standards

The guidelines contained here should be used in all SharePoint development as a standard to ensure consistency, performance, and security.

  • General Coding
    o Follow the .Net Developer’s Guide “Guidelines and Best Practices”:
    o FXCOP is a Microsoft developed utility that checks code against a set of rules. FXCOP should be run on all code, and is available for download from
  • CAML Tools
    The following CAML tools are available for aid with CAML development:
    o U2U: Build, test, and execute CAML queries
    § Provides: U2UCamlCreator.exe application to build CAML query strings in a WYSYWIG fashion, and a reference assembly (U2U.SharePoint.CAML.Server.dll) which encapsulates code for SPQuery class of the WSS OM (which allows execution of CAML query strings)
    § Download from:
    o CAML Viewer 1.0: Allows writing and testing of CAML queries easily (similar to a tool such as SQL Analyzer), viewing the CAML used in list views, and generates and formats code. This tool is based on the object model, and can be downloaded from:
    o CAML Check: Provides for the execution of CAML queries against a list and is based on the object model. This tool does not provide a user interface, however the source code is provided so it can be expended. This tool can be downloaded from:
  • Visual Studio 2005 extensions
    o Visual Studio 2005 extensions for Windows SharePoint Services 3.0 Tools for developing custom SharePoint applications: Visual Studio project templates for Web Parts, site definitions, and list definitions; and a stand-alone utility program, the SharePoint Solution Generator. o Visual Studio 2005 extensions for .NET Framework 3.0 (Windows Workflow Foundation) Provides developers with support for building workflow-enabled applications using Windows Workflow Foundation
  • Web part guidelines:
    o Use ASP.Net 2.0 web parts instead of SharePoint web part, even if calling SharePoint object model code:
    o Do not stream HTML with individual statements, because if an error occurs in the middle of the execution, then the error will be streamed in the middle of the other information. Instead, batch the html with System.Text.StringBuilder and render with HtmlTextWriter
    o If you need to call a Web service, server proxy settings may not have been set, so ensure machine was configured. If it wasn’t, let admin set it in config file, and if it wasn’t set there, then obey the toolpane setting
    o When configuration is required for a web part before it can function, put a link to the configuration dialog in the body of the Web Part; an example of this is the stock ticker web part that requires the input of at least one symbol
    o When using web part properties, set a default value
    o For information on uploading a document programmatically:
    o BaseAreaWebPart is derived from CacheableWebPart, which allows per user or shared caching; also subscribes to the hidden data access web part which issues only one database query per page for performance improvements
    o Reference the following whitepaper that provides in-depth information regarding web parts:
    o Review the items listed in “Best Practices for Developing Web Parts for SharePoint Products and Technologies”
  • Code Access Security
  • Site Templates vs. Site Definitions
    o As a change from SPS 2003, in MOSS 2007, site templates and features are recommended above the use of site definitions.
    o Features are recommended for customizations that require code, and for customizations that may need to be upgraded after the site has been created.
    § Features can be applied using a Site Definition or Site Template Association (Feature Stapling). Please note that this only works with Sites created from a Site Definition.
    o Site templates are recommended for simple customizations that will not need to be changed after they are deployed
  • Localization
    o For localization, all strings must be stored in resource files, not hard coded
  • Monitoring, Logging and Reporting
    o All errors should be logged consistently to the event log using the Microsoft Enterprise Library:
  • Security
    o All code should run as the current user whenever possible
    o No code should bypass SharePoint security and show data to users who do not have appropriate permissions
    o No User Names and Passwords may be stored – use the Business Data Catalog if they are required
    o No in-line code is allowed in Site pages. These are the pages which are created dynamically and stored in the document libraries. SharePoint applies strict security policy on these pages and they run in no-compile mode.
  • Disposing SP Objects properly
    o Make sure SharePoint objects like SPSite and SPWeb are being disposed properly. Do not dispose of any item returned directly from the Microsoft.SharePoint.SPContext.Site or Microsoft.SharePoint.SPContext.Web property except when you obtain reference to these using a constructor or when you use AllWebs. Refer to this article about disposing SharePoint objects:
  • Caching and scalability
    o Follow the guidelines for Data & SharePoint Object Caching and writing scalable code described in the “Common coding issues when using SharePoint Object Model” article at
  • Configuration Data
    o In a shared environment no AppSetting entries are generally allowed in the web.config configuration file of WSS. Instead consider using your own application specific configuration file and store along within your application or feature folder. The feature.xml file should be used for storing Feature properties. A SharePoint list can be considered for storing common configuration data.
  • SharePoint Feature Guidelines
    o All Feature scope should be Site collection scope or lower instead of at the Web-application level. If features can be re-used then they could be deployed at the web-application level.
    o Feature Title should be appropriately named.
    o Provide full description which should include information on the usage, any restrictions, and dependencies on other features, assembly, ownership and contact information. This description should be included in the Feature.xml in addition to any documentation.
  • Upgrade
    o Web Part Upgrade:
    o Solutions:
  • References
    o For a complete reference to best practices, refer to following articles included in the WSS 3.0 SDK 1.1 updated on December 2007.
    o Best Practices: Common Coding Issues When Using the SharePoint Object Model
    o Best Practices: Using Disposable Windows SharePoint Services Objects

No comments:

Post a Comment