In this post we will discuss some of the SharePoint 2010 Best Practices need to follow while developing application for SharePoint 2010.
SharePoint 2010 Best Practices:
If you are using SharePoint Object model then there are certain things to remember that are related to performance, extensibility, and scalability.
While writing code it should ensure that any unmanaged resources should be released as soon as they are no longer needed. Though garbage collector automatically releases memory allocated to unused objects, but it will release in a unpredictable manner. The .NET Framework provides the IDisposable interface, which exposes a Dispose method that you should call to explicitly release these unmanaged resources. To invoke Dispose method, you can use the using keyword, you can use the try/finally code block or you can explicitly invoke Dispose method.
Example of using keyword:
using (SPSite site = new SPSite("URL of the Site Collection"))
// Code here
Internally the compiler converts the using block to try/finally block as shown below.
SPSite site = null;
site = new SPSite("URL of the Site Collection");
// Code here
if (site != null)
The SPSite and SPWeb types both implement the IDisposable interface, and both allocate unmanaged memory. If you do not correctly release SPSite and SPWeb instances, you will probably experience memory leaks, crashes, and frequent application pool recycles.
But if they are derived from the context object then the framework will take care of releasing resources, you should not release the resources.
For example SPWeb web = new SPSite(SPContext.Current.Web.Url).OpenWeb().
Here the web object is derived from the SPContext, so we should not dispose that. Here SPWeb object web.Dispose() automatically called. Read this tutorial Disposing SharePoint Objects
SPDisposeCheck is a tool that analyzes the custom SharePoint solution that uses SharePoint object model. If you can using SPSite or SPWeb objects then it is very much necessary to dispose the objects. Many SharePoint API's allocate COM based memory that is not released by CLR garbage collection and must be released by calling the Dispose() methods. As the name suggests SPDisposeCheck will check your assemblies and will let you know the memory leaks according to the Microsoft standards. It is a command line utility and called by the Visual studio addin. It takes path to a managed .DLL or .EXE or the path to a directory containing many managed assemblies. Then it starts analyzing the memory leaks.
You can download the from the below URL
After downloading this and during installation you can tick on the check boxes to integrate SPDisposeCheck to visual studio 2010.
If you are using SPQuery
object to retrieve data from a large list then you should give a RowLimit else it perform poorly and will fail on large lists. So give RowLimit between 1 and 2000.
Also you should limit the result set in threshold in Microsoft SharePoint Foundation 2010, which is by default 5000 items.
While deploying code using wsp solutions, ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment.
Use the new SharePoint 2010 feature Developer Dashboard
for viewing SharePoint page performance.
If you are working with event receiver then Do not instantiate an SPWeb, SPSite, SPList, or SPListItem object within an event receiver. Because it creates sometimes Significant additional roundtrips to the database and Calls to the Update method on these instances can cause subsequent Update calls in other registered event receivers to fails.
For example follow like below:
So instead of writing like
using (SPSite site = new SPSite(properties.WebUrl))
use like below:
SPWeb web = properties.OpenWeb();
SPListItem item = properties.ListItem;