SharePoint Development Standards

The point of this page is to give you a starting point. It is important that you understand the underlying principles for each standard if you want to know whether it is applicable in your own environment. I have purposely left out most naming conventions but please remember this is only meant as application specific standards. You should always have your own development standards which identify things like naming conventions and approaches.

SharePoint Development Standards

General Principals:
  • All new functionality and customizations must be documented.
    • A schema change could be performed by a SQL script, by manual change, or by code
      that has appropriate permissions to access the SharePoint databases. Any custom code or installation script should always be scrutinized for the possibility that it modifies the SharePoint database.
  • Do not edit out of the box files.
    • For a few well defined files such as the Web.config or docicon.xml files, the built-in files included with SharePoint Products and Technologies should never be modified except through official supported software updates, service packs, or product upgrades.
  • Do not directly access the databases.
    • Any addition, modification, or deletion of the data within any SharePoint database using database access commands. This would include bulk loading of data into a database, exporting data, or directly querying or modifying data.
    • Directly querying or modifying the database could place extra load on a server, or could
      expose information to users in a way that violates security policies or personal information management policies. If server- side code must query data, then the process for acquiring that data should be through the built-in SharePoint object model, and not by using any type of query to the database. Client-side code that needs to modify or query data in SharePoint Products and Technologies can do this by using calls to the built-in SharePoint Web services that in turn call the object model.

      • Exception: In SharePoint 2010 the Logging database can be queried directly as this database was designed for that purpose.
  • Do not modify the Database Schema.
    • Any change made to the structure or object types associated with a database
      or to the tables included in it. This includes changes to the SQL
      processing of data such as triggers and adding new User Defined Functions.
    • A schema change could be performed by a SQL script, by manual change, or by code that has appropriate permissions to access the SharePoint databases. Any custom code or installation script should always be scrutinized for the possibility that it modifies the SharePoint database
  • In SharePoint 2007 Site and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable.
  • Use best practices when accessing data using the SharePoint object model. See Working with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services Objects
Development Decisions:
There are plenty of challenging decisions that go into defining what the right solution for a business or technical challenge will be. What follows is a chart meant to help developers when selecting their development approach.
Sandbox Apps Farm
When to use Deprecated. Therefore, it’s unadvisable to build new sandboxed solutions. Best practice. Create apps whenever you can. Create farm solutions when you can’t do it in an app. See SP 2013 apps vs farm solutions for more info.
Server-side code Runs under a strict CAS policy and is limited in what it can do. No SharePoint server-code. When apps are hosted in an isolated SharePoint site, no server-code whatsoever is allowed. Can run full trust code or run under fine grained custom CAS policies.
Resource throttling Run under an advanced resource management system that allows resource point allocation and automatic shutd style=”border:1px solid black;vertical-align:text-top”own for troublesome solutions. Apps run isolated from a SharePoint farm, but can have an indirect impact by leveraging the client object model. Can impact SharePoint server-farm stability directly.
Runs cross-domain No, and there’s no need to since code runs within the SharePoint farm. Yes, which provides a very interesting way to distribute server loads. No, and there’s no need to since code runs within the SharePoint farm.
Efficiency/Performance Runs on the server farm, but in a dedicated isolated process. The sandbox architecture provides overhead. Apps hosted on separate app servers (even cross-domain) or in the cloud may cause considerable overhead. Very efficient.
Safety Very safe. Apps rely on OAuth 2.0. The OAuth 2.0 standard is surrounded by some controversy (for example, check out what OAuth lead author Eran Hammer has to say about it here: OAuth 2.0 Road To Hell. In fact, some SharePoint experts have gone on the record stating that security for Apps will become a big problem. We’ll just have to wait and see how this turns out. Can be very safe, but this requires additional testing, validation and potential monitoring.
Should IT pros worry over it? Due the the limited CAS permissions and resource throttling system, IT pros don’t have to worry. Apps are able to do a lot via the client OM. There are some uncertainties concerning the safety of an App running on a page with other Apps. For now, this seems to be the most worry-able option, but we’ll have to see how this plays out. Definitely. This type of solutions run on the SharePoint farm itself and therefore can have a profound impact.
Manageability Easy to manage within the SharePoint farm. Can be managed on a dedicated environment without SharePoint. Dedicated app admins can take care of this. Easy to manage within the SharePoint farm.
Cloud support Yes Yes, also support for App MarketPlace. No, on-premises (or dedicated) only.
App Development (SharePoint 2013):
  • When developing an app select the most appropriate client API:
    • Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server separated by a firewall benefit most from using the JavaScript client object model.
    • Server-side code in Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server but not separated by a firewall mainly benefit from using the .managed client object model, but the Silverlight client object model, JavaScript client object model or REST are also options.
    • Apps hosted on non-Microsoft technology (such as members of the LAMP stack) will need to use REST.
    • Windows phone apps need to use the mobile client object model.
    • If an App contains a Silverlight application, it should use the Silverlight client object model.
    • Office Apps that also work with SharePoint need to use the JavaScript client object model.
Quality Assurance:
  • Custom code must be checked for memory leaks using SPDisposeCheck.
    • False positives should be identified and commented.
  • Code should be carefully reviewed and checked. As a starting point use this code review checklist (and provide additional review as needed).
  • Provide an Installation Guide which contains the following items (Note this relates to SharePoint Deployment Standards):
    • 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.
Branding:
  • A consistent user interface should be leveraged throughout the site. If a custom application is created it should leverage the same master page as the site.
  • Editing out of the box master pages is not allowed. Instead, duplicate an existing master page; make edits, then ensure you add it to a solution package for feature deployment.
  • When possible you should avoid removing SharePoint controls from any design as this may impact system behavior, or impair SharePoint functionality.
  • All Master Pages should have a title, a description, and a preview image.
  • All Page Layouts should have a title, a description, and a preview image.
Deployment:
  • All custom SharePoint work should be deployed through SharePoint Solution (.wsp) files.
  • Do not deploy directly into SharePointRoot (12, 14 Hives) Folders. Instead deploy into a folder identified by Project Name.
Features:
  • Features must have a unique GUID within the farm.
  • Features with event receivers should clean up all changes created in the activation as part of the deactivation routine.
    • The exception to this is if the feature creates a list or library that contains user supplied data. Do not delete the list/library in this instance.
  • Features deployed at the Farm or Web Application level should never be hidden.
  • Site Collection and Site Features may be hidden if necessary.
  • Ensure that all features you develop have an appropriate name, description, updated version number and icon.
SharePoint Designer:
  • SharePoint Designer 2007 updates are generally not allowed.
    • The only exception to this rule is for creating DataForm Web Parts.
    • The following is a recommended way of managing this aspect:
      Create a temporary web part page (for managing the manipulation of a data view web part). Once the web part is ready for release and all modifications have been made export the .webpart and then delete the page. You can now import it onto a page elsewhere or place it in the gallery. This way none of your production pages are un-ghosted. The other advantage is that you can place the DVWP on a publishing page (as long as there are web part zones to accept them).
    • DataForm Web Parts should be exported through the SharePoint GUI and solution packaged for deployment as a feature.
    • This does not mean that SharePoint Designer should not be used for creating and testing branding artifacts such as master pages and page layouts.
      • It is important for these artifacts to be deployed through solution files (WSPs) and typical build and deployment processes and not by manual methods.
  • SharePoint Designer 2010 updates are generally only allowed by a trained individual.
    • The following is a recommended way of managing the creation of DataForm Web Parts:
      Create a temporary web part page (for managing the manipulation of a data view web part). Once the web part is ready for release and all modifications have been made export the webpart and then delete the page. You can now import it onto a page elsewhere or place it in the gallery. This way none of your production pages are un-ghosted. The other advantage is that you can place the DVWP on a publishing page (as long as there are web part zones to accept them).
    • DataForm Web Parts should be exported through the SharePoint GUI and solution packaged for deployment as a feature.
  • SharePoint Designer workflows should not be used for Business Critical Processes.
    • They are not portable and cannot be packaged for solution deployment.
      • Exception Note: Based on the design and approach being used it may be viable in SharePoint 2010 for you to design a workflow that has more portability.
        This should be determined on a case by case basis as to whether it is worth the investment and is supportable in your organization.
Site Definitions:
  • In SharePoint 2007 Site and list templates must be created through code and features (site and list definitions).
    • STP files are not allowed as they are not updatable.
  • Site definitions should use a minimal site definition with feature stapling.
Solutions:
  • Solutions must have a unique GUID within the farm.
  • Ensure that the new solution version number is incremented (format V#.#.#).
  • The solution package should not contain any of the files deployed with SharePoint.
  • Referenced assemblies should not be set to “Local Copy = true”
  • All pre-requisites must be communicated and pre-installed as separate solution(s) for easier administration.
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.
InfoPath:
  • If an InfoPath Form has a code behind file or requires full trust then it must be packaged as a solution and deployed through Central Administration.
  • If an InfoPath form does not have code behind and does not need full trust the form can be manually published to a document library, but the process and location of the document library must be documented inside the form.
    • Just add the documentation text into a section control at the top of the form and set conditional formatting on that section to always hide the section, that way users will never see it.
WebParts
  • All WebParts should have a title, a description, and an icon.
Application Configuration
  • There are only a few methods in which application configuration data can be stored. When selecting the option that is right for the situation any decision maker must review this article Managing Custom Configuration Options for a SharePoint Applicationbefore making the decision.
    • Web.config
      • APIs such as the ConfigurationSection class and SPWebConfigModification class should always be used when making modificationsto the Web.config file.
      • HTTPModules, FBA membership and Role provider configuration must be made to the Web.config.
    • Property Bags
      • It is recommended that you create your own _layouts page for your own settings.
      • It is also recommended that you use this codeplex tool to support this method http://pbs2010.codeplex.com/
    • Lists
      • This is not a recommended option for Farm or Web Application level configuration data.
      • It is also recommended that you use this codeplex tool to support this method http://spconfigstore.codeplex.com/
    • Hierarchical Object Store (HOS) or SPPersistedObject
      • Ensure that any trees or relationships you create are clearly documented.
      • It is also recommended that you use the Manage Hierarchical Object Store feature at http://features.codeplex.com/. This feature only stores values in the Web Application. You can build a hierarchy of persisted objects but these objects don’t necessarily map to
        SPSites and SPWebs.
References:
Is this missing anything? Comment below and let me know,
Richard Harbridge

{ 4 trackbacks }

SharePoint Saturday at Microsoft Waltham: Attendee Notes « Tech Notes
April 10, 2011 at 11:59 pm
Update to SharePoint Development Standards
October 12, 2011 at 6:14 pm
The 7 Most Important SharePoint Online Success Factors #o365redmond | SNS Online
March 6, 2012 at 2:47 pm
Updates for SharePoint 2013 to SharePoint Development Standards and SharePoint Content Standards
February 19, 2013 at 9:10 pm

{ 10 comments… read them below or add one }

1 Bil Simser August 17, 2010 at 10:44 am

Great stuff. This is a fabulous resource and one I’m looking to adopt, use, and spread amongst my team. There are lots of things that could be added but I think it is important to keep things terse.

On the SharePoint Designer side as a general practice I always create a web part page (usually named “deleteme” or something silly) to manipulate data view web parts. Once the work is done I export the .webpart and import onto my page elsewhere (or put it in the gallery) and delete the scratch web part page. This way none of my production pages are ghosted. The other advantage is that I can put my DVWP on a publishing page (as long as there are web part zones to accept them).

Thanks and keep up the great work!

Reply

2 Richard Harbridge August 17, 2010 at 11:25 am

Love the clarity and concept Bill. I have added this to the listing as a reference! 🙂

Reply

3 Seth August 17, 2010 at 12:24 pm

I’m glad my post was helpful to you. You’ve got a great list going here. I’m going to update my post with a link to this one for further reference.

Reply

4 Seth August 17, 2010 at 12:31 pm

Also to answer your question, I haven’t had enough experience with custom SharePoint 2010 work to comment on those standards yet. But when I do, I’ll let you know if I have anything to contribute. Thanks!

Reply

5 David Lozzi August 31, 2010 at 5:23 pm

Priceless! Thanks for this comprehensive collection! I look forward to the 2010 version!

Is there a PDF/Word doc available?

Thanks,
David

Reply

6 Richard Harbridge September 1, 2010 at 12:51 pm

Will be one soon. I think I will wait a little bit longer to see if anyone else in the community has more to add.

Reply

7 Rene October 5, 2010 at 10:06 am

Hi Richard,

how do you include “client side” development, e.g. with jQuery, in here? For example, how should such code be deployed, how should the pages that use it be handled (that is in my opinion quite similar to your SPD section here).

Cheers,
Rene

Reply

8 Richard Harbridge October 14, 2010 at 3:24 pm

A great point! I will have to think it over and ping a couple other people to see if they agree with some recommendations I would have.

Reply

9 Manoj January 16, 2011 at 3:24 am

great work, looking forward to 2010 version and a pdf too..

Reply

10 Nilesh Mehta December 12, 2011 at 2:16 pm

Great Work!!! Definitely looking forward to learning from this article and implementing best practices.

Reply