SharePoint apps and farm solutions require all sorts of system resources. These resources could involve memory, system handles or even database connections. Not dealing correctly with them can introduce nasty bugs and performance issues. The .NET CLR supports automatic memory management, using the garbage collector. But other resources need to be dealt with using bespoke code. To help with this many developers and administrators are using SPDisposeCheck. But beware – that tool is broken and continuing to use it is dangerous!
75% of farm solutions in SharePoint 2013 have memory leaks*!
A common problem with SharePoint, and in particular with SharePoint 2013 full trust farm solutions, is memory leaks. Many SharePoint server side API’s rely on COM objects which are not managed by the .NET garbage collector. So, if you don’t dispose of certain objects – like SPWeb and SPSite – you’ll run the risk of encountering some memory leaks. In turn, this will have a huge impact on your SharePoint farm. If a piece of affected code is executed frequently (let’s say on the intranet landing page), memory usage of the w3wp.exe process of the Internet Information Server (IIS), used by SharePoint, can increase rapidly. When the server(s) inevitably run out of memory, IIS will recycle the application pool. This can result in a loss of information, temporary time-outs, and generally an unstable platform.
Even worse memory leaks can lead to unfulfilled service level agreements (SLA), time and money being wasted for troubleshooting in support, operations and development and end-users being affected by a poor performing platform. This is about risk mitigation and failure prevention.
* This statistic was gathered from over 1200 unique farm solutions analyzed by SPCAF, whose anonymized results have been submitted since May 2015 through the SPCAF Benchmark Program.
84% of SharePoint Professionals believe to have memory leaks under control!
…or are unaware of the problem!
We just recently closed our 1 month survey “The State of SharePoint and Office 365 Development” in which we asked the over 1000 participants if they use SPDisposeCheck to check for memory leaks, and if yes, do they use it for their SharePoint 2013 customizations too. The result was even more shocking than we have anticipated.
Of those participants who customize their SharePoint 2013 environment with farm solutions, over 84% use either no tool, or tools that don’t work (read further down why those tools are useless)
Of those 84% the participants work primarily in the following roles in their teams:
Which group do you belong to? If you belong to those 84% then better read on!
Disposing of resources in SharePoint
Memory leaks are very common in any custom code, but the garbage collector will decrease the risk of excessive memory usage for managed code. As SharePoint relies on unmanaged COM objects, they are ignored by the garbage collector. The w3wp.exe process running full trust code in a farm solution will keep a reference to any unmanaged COM object that has not been explicitly released by managed code. A common issue with SharePoint farms using custom full trust farm solutions are random application pool recycles. In most cases this is caused by the server running out of available memory, resulting in IIS trying to free up memory by an unexpected application pool recycle.
The key to avoiding this problem is to dispose of every created SPWeb and SPSite object. However, you should not dispose of properties of type SPWeb or SPSite, e.g. SPWeb.ParentWeb, or SPSite.RootWeb. When your code disposes of the parent object, it’s not necessary to dispose of any child properties like ParentWeb or RootWeb. If you do it anyway, other pieces of code (also out-of-the-box SharePoint) that relies on the availability of those properties will receive a NullReferenceException and requires to recreate those objects. This again has negative impact on performance and stability of your SharePoint farm.
To make things even more complex, objects created by calling a method like SPSite.OpenWeb() must be disposed of.
Another good tip, never dispose of the objects inside the static object SPContext.Current or retrieved via a property bag, eg. in an event receiver. This may also break a lot of functionality, even out of the box SharePoint code.
These are rather simple examples that might be not that hard to remember, but let me show you a more complex one which occurs when you forget to close the PublishingWeb created by calling PublishingWeb.GetVariation and easy to miss.
Bad Practice
void GetVariationLeak()
{
using (SPSite siteCollection = new SPSite("http://moss"))
{
using (SPWeb web = siteCollection.OpenWeb())
{
PublishingWeb publishingWeb = PublishingWeb.GetPublishingWeb(web); // Passing in SPWeb object, so no Close() needed
VariationLabel variationLabel = Variations.Current.UserAccessibleLabels[0];
PublishingWeb variationPublishingWeb = publishingWeb.GetVariation(variationLabel); // Must be Closed().
// ...
} // SPWeb object outerWeb.Dispose() automatically called.
} // SPSite object siteCollection.Dispose() automatically called.
}
Good Practice
void GetVariationNoLeak()
{
using (SPSite siteCollection = new SPSite("http://moss"))
{
using (SPWeb web = siteCollection.OpenWeb())
{
PublishingWeb variationPublishingWeb = null;
try
{
PublishingWeb publishingWeb = PublishingWeb.GetPublishingWeb(web); // Passing in SPWeb object, so no Close() needed.
VariationLabel variationLabel = Variations.Current.UserAccessibleLabels[0];
variationPublishingWeb = publishingWeb.GetVariation(variationLabel); // Must be Closed().
// ...
}
finally
{
if(variationPublishingWeb != null)
variationPublishingWeb.Close();
}
} // SPWeb object web.Dispose() automatically called.
} // SPSite object siteCollection.Dispose() automatically called.
}
There are many more things to keep in mind when properly disposing of SharePoint objects. This page on the MSDN site is one resource that attempts to educate developers when it comes to SharePoint and best practice in this area. But beware, it is not only incomplete, it talks about a tool called SPDisposeCheck – and herein lies the main advice of this post!
There’s an enemy out there and it’s broken…. SPDisposeCheck!
When Microsoft released SharePoint 2007, they also published the SPDisposeCheck tool to analyze farm solutions for any possible memory leak. It was available as a command line tool to analyze a DLL, and later-on as a Visual Studio add-in. When SharePoint 2010 was released there was a thriving community of developers writing custom code solutions. Not every dev knew about SPDisposeCheck, but those that did found it very useful.
However, because of major changes that came with SharePoint 2013, SPDisposeCheck stopped working. The reason? SharePoint 2007 & 2010 are based on .NET 2.0 while SharePoint 2013 is based on .NET 4.5. SPDisposeCheck is also based on .NET 2.0, and thus is unable to analyze .NET 4.5 assemblies. When run against SharePoint 2013 farm solutions, it will still run, but never actually throw up any warning. This can cause some serious problems and is a very dangerous situation for the many developers that have started relying on it! Why exactly? Any problems in your code won’t be highlighted. Disposal errors will still be there and you’ll have no idea about it.
The tool is still available for download on several sites (I won’t link any of them), but it has been removed by Microsoft from most of their official sites. As I wrote on my blog back in 2013, developers and IT Pros should no longer use SPDisposeCheck to analyze code when customizing SharePoint 2013 or later. When you think that according to our survey today over 90% of IT Pros/Administrators either still think they can check memory leaks with SPDisposeCheck or are not even aware of the problem, it is a seriously alarming situation and needs to change quickly.
How about MSOCAF?
Microsoft provides also a tool called the “Microsoft SharePoint Online Code Analysis Framework (MSOCAF)” (not to be confused with our own SPCAF) that is available in a SharePoint 2010 and a SharePoint 2013 version. MSOCAF checks against 122 code quality rules (compared to >700 in SPCAF) and also integrates FxCop and SPDisposeCheck.
But if you believe now that the SharePoint 2013 version of MSOCAF is checking for memory disposal in SharePoint 2013 assemblies then you are unfortunately mistaken!
MSOCAF is using SPDisposeCheck as if you would run it standalone, hence it is similar useless for those types of assemblies and again gives you a false sense of security.
You can find a comparison chart between MSOCAF and SPCAF on our website.
Don’t believe me? Try it yourself!
Let’s do a simple test.
- Create a Visual Studio solution which implements every single BAD practice described in
- Compile the assembly targeting
- Run each with:
- Review the results!
And let me tell you, the results are pretty obvious 🙂
| SP2010 Assembly (.NET 2.0) | SP2013 Assembly (.NET 4.5) | |
|---|---|---|
| SPDisposeCheck | 42 errors | 0 errors |
| MSOCAF | 42 errors | 0 errors |
| SPCAF | 57 errors | 57 errors |
Both SPDisposeCheck and MSOCAF report ZERO errors in SharePoint 2013 assemblies!
If you believe pictures more than tables, here is MSOCAF:
SPDisposeCheck:
and the SPCAF Report:
You could be at risk. Check your code now!
Of course I recommend as an alternative our own SharePoint Code Analysis Framework (SPCAF). It is now the only tool that supports both disposal checks and all round code quality, performance and security analysis in SharePoint 2013 (indeed all versions of SharePoint). Besides memory leak analysis, the tool will do so much more, for example code analysis, possible upgrade issues, compliancy verification, compatibility checks for a certain SharePoint version etc.
In terms of memory leak analysis SPCAF does all the checks SPDisposeCheck did, but also does checks that were absent in SPDisposeCheck and fixes plenty of false positives and negatives that annoyed so many developers already!
SPCAF verifies any WSP (SharePoint 2007 – 2019), executable or DLL against 26 memory disposal rules that you can read about in detail in our SPCAF documentation.
Read more about SPCAF on our website, or get a trial from the download section to see if your code is affected too!
SPDisposeCheck is broken:
Spread the word!
So which group do you belong to?
- You didn’t know there was a problem?
- Thought you were safe with SPDisposeCheck?
- Lucky user of SPCAF?
We want to unite SharePoint teams and produce the best solutions we can. We can only do this by communicating what works well and what doesn’t. In this case SPDisposeCheck and MSOCAF clearly don’t and can be extremely harmful to your solutions and farms.
So talk to your colleagues, talk to your teams, talk to your friends and let them know about the dangers of using SPDisposeCheck and MSOCAF with SharePoint 2013 customizations. And if you still need more convincing, try it yourself by downloading the test assemblies or analyzing your own code with the SPCAF Trial! Click the button below to try SPCAF for free!
