SharePoint Development Best Practices [Custom Development using Visual Studio]

Here in the SharePoint development tutorial, we will discuss SharePoint development best practices while developing a custom solution using visual studio 2017/2015 for SharePoint 2016/2013/2010.

There are various best practices needs to be followed for developing a robust custom solution for SharePoint.

SharePoint deveopment training course

SharePoint development best practices

If you are using SharePoint Object model to develop custom solution then there are certain things to remember that are related to performance, extensibility, and scalability.

Approach-1:
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, it will release in an 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 the 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;
try
{
site = new SPSite(“URL of the Site Collection”);
// Code here
}
finally
{
if (site != null)
site.Dispose();
}
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 of that. Here SPWeb object web.Dispose of () automatically called. Read this tutorial Disposing SharePoint Objects.

Approach-2:
SPDisposeCheck is a tool that analyzes the custom SharePoint solution that uses the SharePoint object model. If you can using SPSite or SPWeb objects then it is very much necessary to dispose of 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 add-in. It takes the 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 them from this URL.

After downloading this and during installation you can tick on the checkboxes to integrate SPDisposeCheck to visual studio 2010.

Once the Integration happens it can be found under Tools -> SharePoint Dispose Check in Visual Studio.

Approach-3:
SPQuery:
If you are using the SPQuery object to retrieve data from a large list then you should give a RowLimit else it performs poorly and will fail on large lists. So give RowLimit between 1 and 2000.

Also, you should limit the result set in the threshold in Microsoft SharePoint Foundation 2010, which is by default 5000 items.

Approach-4:
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.

Approach-5:
Use the new SharePoint 2010 feature Developer Dashboard for viewing SharePoint page performance.

Approach-6:
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;

You may like following SharePoint custom solutions:

Hope this SharePoint best practices tips will be helpful to develop a robust SharePoint custom solution using visual studio 2010/2015/2017.

Check out Best Alternative to InfoPath -> Try Now

free sharepoint training

SharePoint Online FREE Training

JOIN a FREE SharePoint Video Course (3 Part Video Series)

envelope
envelope

About Bijay Kumar

I am Bijay from Odisha, India. Currently working in my own venture TSInfo Technologies in Bangalore, India. I am Microsoft Office Servers and Services (SharePoint) MVP (5 times). I works in SharePoint 2016/2013/2010, SharePoint Online Office 365 etc. Check out My MVP Profile.. I also run popular SharePoint web site SharePointSky.com

View all posts by Bijay Kumar →