Importance of Standards in SharePoint Development

So I’m going to spend a few moments on my soapbox here…

SharePoint is an amazing application platform and through the use of many different 3rd party tools and custom code it can do just about anything.  As developers who know SharePoint we may be tempted to custom code something that is similar to SharePoint functionality, but just needs a few little tweaks to be perfect for the business.

This is such a dangerous path.  Most SharePoint developers are .NET developers, but not all .NET developers are SharePoint developers.  Due to the restrictions that SharePoint places on the code, often times I find that .NET developers code around these “limitations” which can cause security and coding issues down the road.

That being said, here are some quick bullet points to get started:

Assembly Development:

• The assembly file name should follow this format:
  • [Customer].[Supplier Name].[Solution name].dll
  • example: Adventureworks.JSolutions.Branding.dll
• The assembly version number should be as the solution version number.
• Use the .Net XML commenting system
  (http://msdn.microsoft.com/en-us/library/b2s063f7.aspx)
• Use the standard naming conventions as defined by Microsoft (http://msdn.microsoft.com/en-us/library/xzf533w0.aspx)
• Follow Microsoft’s best practices for SharePoint development (http://msdn.microsoft.com/en-us/magazine/dd458798.aspx)
• Follow Microsoft’s security guidelines for ASP.NET development (http://msdn.microsoft.com/en-us/library/ms998258.aspx)

File Headers:

• In the top section of each file (code, xml, aspx, etc) supply the following information:
  • Company name and copy rights
  • Author name
  • File
  • Purpose
  • Create Date

Custom Configuration:
Config File:

• When possible try to not store custom settings in the web.config file. Use a separate file on CONFIG folder.
• File name should follow this format:
  • [Customer]_[Supplier Name]_[Solution name]_Configuration.config example:Adventureworks_JSolutions_Branding_Configuration.config
• Entries to web.config keys must be communicated beforehand to the customer.
• Entries to web.config (user names or passwords) must be encrypted.
• Entries to the web.config should be inside a block of comment which contains the solution name and description.

Property Bag:

• Should be used for storing only primitive types.
• If the values are user-defined, provide a web interface to edit those properties from custom actions on central administration on each property scope.

Features:

• Ensure that each feature GUID is unique in the farm.
• Ensure that each feature folder name and title should follow this format:
  • [Customer].[Supplier Name].[Solution name].[Feature Name]
  • example: Adventureworks.JSolutions.Branding.HideLinks
• Ensure that all the features has a appropriate name, description, updated version number and icon.
• Features with event receivers should clean up all changes created in activation as part of the deactivation routines. If the feature creates a list that contains user data, the feature should not delete this list.
• Farm and Web Application features should never be hidden.
• Site Collection and Site features should be hidden.

Solution (WSP):

• Ensure that new solutions have a unique GUID in the Farm
• Ensure that the new solution version number is incremented (format V#.#.#)
• Solution naming convention must be descriptive:
  • [Client Name].[Supplier Name].[Solution or module name]_[Version number].wsp
  • example: Adventureworks.JSolutions.Branding_v1.0.0.wsp
• In case of an update solution action is required for installation,solution name must not be changed.
• The solution package should not include any of SharePoint installed files.
• Referenced assemblies should not be set to copy local = ‘true’.
• All prerequisites must be communicated to the customer and pre-installed as stand-alone components for easier administration.

Tools for Building the Solution:

• Use WSPBuilder for creating SharePoint Solutions.
• Use CAML Query Builder tool to generate CAML queries used in the source code.
• Use SharePoint Designer 2007 to create master pages, page layouts, style sheets.

Tools for Quality Assurance:

• Use FXCop for identifying and fixing performance and security issues in source code.
• Use the CAT.NET to help identify security issues in the solution source code.
• Use StyleCop to identify code style and naming conventions issues.
• Use the SPDisposeCheck tool

Source Control:

• All source code must be under a proper source control (like TFS or SVN).
• All internal builds must have proper labels on source control.
• All releases have proper labels on source control.

Quality Assurance:

• If you use the MVP pattern, create unit tests for each unit of your solution.
• Follow Microsoft’s best practices for SharePoint development (http://msdn.microsoft.com/en-us/library/aa973248.aspx)
• Run FXCop, CAT.NET, StyleCop and SPDisposeChecker on all code.
• Follow Microsoft’s security guidelines for ASP.NET development (http://msdn.microsoft.com/en-us/library/ms998258.aspx)

Release to Customer:

• Provide an Installation Guide which contains the following items:
  • Solution name and version number.
  • Targeted environments for installation.
  • Software and hardware Prerequisites: explicitly describes what is all needed updates, activities, configurations, packages, etc. that should be installed or performed before the package installation.
  • Deployment steps: Detailed steps to deploy or retract the package.
  • Deployment validation: How to validate that the package is deployed successfully.
  • Describe all impacted scopes in the deployment environment and the type of impact.