Wednesday, 12 January 2011

SharePoint 2007 and SharePoint 2010 Best Practice - Run SPDisposeCheck as part of your Build process with an Error Condition

One of the most common (and frustrating) sources of memory leak issues in SharePoint 2007 and SharePoint 2010 applications lies in the incorrect disposal of objects with unmanaged components. Memory leak issues typically show themselves in symptoms like:
  1. Excessive paging on the server and low memory issues
  2. The IIS application pools recycling themselves repeatedly
  3. Generally sluggish performance for end users (as the RAM gets eaten up by referenced SharePoint objects)
Why doesn't the .NET garbage collector clean them out of memory? Because the .NET objects are typically small - but it's the unmanaged (invisible to the .NET framework) that ravenously consumes your server's precious memory.

So what objects normally cause these issues? The prime suspects are normally undisposed instances of the SPSite and SPWeb classes - as detailed extensively on MSDN here:

I'm a firm believer in automated testing and code auditing tools - so to preemptively avoid such issues with disposal of unmanaged objects, I recommend to all of my SharePoint clients that you must have SPDispose check as part of your regular build process in any SharePoint Project. This avoids any existing code or any new code killing your SharePoint Farm with "unmanaged object bloat".

As described by the SPDisposeCheck documentation:
"SPDisposeCheck is a tool to help you to check your assemblies that use the SharePoint API so that you can build better code. It provides assistance in correctly disposing of certain SharePoint objects to help you follow published best practice. This tool may not show all memory leaks in your code. Further investigation is advised if you continue to experience issues.  New features in this release include VS 2008 and 2008 add-in, added “Do Not Dispose Rules”, bug fixes, and updated for WSS 3.0 / MOSS 2007 and SPF / SharePoint Server 2010. "

The great thing about this latest release is that it will even tell you when you are unneccesarily disposing your SharePoint objects.

I didn't have much luck with the Visual Studio Add-in in the latest version of SPDisposeCheck (it would never run a check). As an alternative, I suggest you implement this command as part of your After build in project properties for each of your projects:

"C:\Program Files (x86)\Microsoft\SharePoint Dispose Check\SPDisposeCheck.exe" "$(TargetPath)"

[Alternatively, you can copy the executable to a solution folder and use a relative path]. This commandline will fail the project (returning a non-zero value) if there are any problems - preventing a build from occurring unless the problem is fixed or you use the "SPDisposeCheckIgnoreAttribute" on your method. Unfortunately there are no binaries currently to reference so you can consume this attribute in your code. Instead, you can obtain the source code for the SPDisposeCheckIgnoreAttribute from the following directory once you've installed the SPDisposeCheck msi:

C:\Program Files (x86)\Microsoft\SharePoint Dispose Check\\SPDisposeExamplesSource

No comments: