SharePoint Coding Practices – A Quick Overview

Article
07/29/2009

Aravindhan Rajagopal here. I am a developer from Information Security Tools team.

I had been working on couple of SharePoint projects in my team for the past couple of years and thought of posting a blog which would be helpful for beginners in particular to get the necessary guidance in this space. I will go through SharePoint coding standards, SharePoint templates to work with during feature staple etc., in this blog. Recently we have developed a custom data classification solution for our intranet SharePoint sites and I had a chance to learn a few critical guidelines with respect to SharePoint coding during that project.

Working with AllowUnsafeUpdates Property.

As pointed out by MSDN articles to developers, having this property set to true, opens up security risks like cross site scripting. So unless otherwise its critically needed, we should not be setting this property. If we are sure about the risks and would like to perform some updates during a POST request, then we should make sure we turn it off after performing our intended operations. For eg., in a try catch block, you have a series of operations to be done including updates to the spweb and spsite objects, you might end up enabling the allowunsafeupdates to true. Assume for some reason that you get an exception while processing a few statements, after setting this property to true. If this property is not reset back to false after you get an exception, it would result in an open risk. As a best practice, we should have a finally block with the statement AllowUnsafeUpdates = false in order to avoid any unexpected updates/attacks.

Eg., usage of AllowUnsafeUpdates Property

try { AllowUnsafeUpdates = true; // Perform the updates } catch (Exception ex) { // Log it } finally { AllowUnsafeUpdates = false; }

SPSite and SPWeb objects Usage

Whenever we create SPSite objects in our code, we should make sure that we dispose those objects after use. If they are not disposed, it would cause a memory leak. The following are the two best examples on how to handle SPSite objects and its disposal.

Example 1.

 SPSite site = null;

 try{ site = new SPSite(url)  web.OpenWeb();}Catch (Exception ex){    // Logging}finally{  if (site !=null)   {       site.Dispose(); }}

Example 2.

Even better approach would be to use the Using Clause. This helps developers to stop worrying about disposing as it automatically disposes the objects.

using (site = new SPSite(url)) { // Perform Actions }

It should also be noted that Response.Redirect when used inside a try catch block (like in Example 1), we should dispose the objects before redirection without fail. Example 1 should be modified as shown below

 SPSite sSite = null;

 SPWeb sWeb = null;

 try{ sSite = new SPSite(url);    web.OpenWeb();

         if (sWeb!=null)  {       sWeb.Dispose(); }

         if (sSite !=null) {       sSite.Dispose();    }

         Response.Redirect("another.aspx");

 }Catch (Exception ex){   // Logging}finally{        if (sWeb!=null)  {       sWeb.Dispose(); }

    if (sSite !=null)  {       sSite.Dispose();    }}

You may find that the Using clause stands tall in these situations!

There is one last thing with respect to SPWeb objects, that we cannot ignore.

Never dispose an SPWeb object derived from SPContext. Disposing a context derived SPWeb object will cause other SharePoint API calls to fail if they try to access it.

Do you want another pair of eyes (read virtual eyes) to do a code check for all object disposals? Yes. There is a tool readily available for that. Its the SharePoint Dispose Checker Tool.

You can go through a much more elaborate best practices guide at

https://msdn.microsoft.com/en-us/library/aa973248.aspx

Recently we did a data classification feature for all the sharepoint sites that were being created in our organization. Since there are umpteen blogs and msdn articles on how to feature staple, we would not go through them again…the following are the different templates that are available in sharepoint, the names of which should be mentioned in the feature stapling xml as shown below

<?xml version="1.0" encoding="utf-8" ?>

</Elements>

where ID stands for the GUID of the feature you are trying to staple.

Template Name	Description
GLOBAL#0	Global template (1033)
STS#0	Team Site (1033)
STS#1	Blank Site (1033)
STS#2	Document Workspace (1033)
MPS#0	Basic Meeting Workspace (1033)
MPS#1	Blank Meeting Workspace (1033)
MPS#2	Decision Meeting Workspace (1033)
MPS#3	Social Meeting Workspace (1033)
MPS#4	Multipage Meeting Workspace (1033)
CENTRALADMIN#0	Central Admin Site (1033)
WIKI#0	Wiki Site (1033)
BLOG#0	Blog (1033)
BDR#0	Document Center (1033)
OFFILE#0	Records Center (1033)
OFFILE#1	Records Center (1033)
OSRV#0	Shared Services Administration Site (1033)
SPS#0	SharePoint Portal Server Site (1033)
SPSPERS#0	SharePoint Portal Server Personal Space (1033)
SPSMSITE#0	Personalization Site (1033)
SPSTOC#0	Contents area Template (1033)
SPSTOPIC#0	Topic area template (1033)
SPSNEWS#0	News Site (1033)
CMSPUBLISHING#0	Publishing Site (1033)
BLANKINTERNET#0	Publishing Site (1033)
BLANKINTERNET#1	Press Releases Site (1033)
BLANKINTERNET#2	Publishing Site with Workflow (1033)
SPSNHOME#0	News Site (1033)
SPSSITES#0	Site Directory (1033)
SPSCOMMU#0	Community area template (1033)
SPSREPORTCENTER#0	Report Center (1033)
SPSPORTAL#0	Collaboration Portal (1033)
SRCHCEN#0	Search Center with Tabs (1033)
PROFILES#0	Profiles (1033)
BLANKINTERNETCONTAINER#0	Publishing Portal (1033)
SPSMSITEHOST#0	My Site Host (1033)
SRCHCENTERLITE#0	Search Center (1033)
SRCHCENTERLITE#1	Search Center (1033)
SPSBWEB#0	SharePoint Portal Server BucketWeb Template (1033)

Please get back to me with any questions on topics covered in this blog. I plan to blog on SharePoint customizations in the coming weeks.

SharePoint Coding Practices – A Quick Overview

Additional resources