I like many SharePoint developers out there I am user of SPDisposeCheck. My team and I use this as in our Continuous Integration builds as one of our quality checks on to determine if our code is passing the checks we need for a ‘green’ build.

In fact SPDisposeCheck is so valuable in terms of catching issues before they get into any live code from my team I consider it to be, borrowing from Doug Ware’s metaphor, the safety catch on my machine gun.

During beta we discovered that SPDisposeCheck was not working for SharePoint 2013.

Consider this code:

Now most of you who have done a bit of SharePoint development should be able to see that code has a gaping memory leak and should not pass SPDisposeCheck.

Yeah, that’s not ideal…

But what about static code analysis? Microsoft.Reliability: CA2000 Dispose objects before losing scope is supposed to catch things like this too, right? Unfortunately this memory leak slips right past that check too.

This still has not been resolved. Yes, if you were doing SharePoint 2013 and thinking that you’re doing the right thing, using SPDisposeCheck, you need to do a code review. Now.

Myself and other SharePoint MVPs who are development focused are doing our best to keep this on the radar within Microsoft.

I for one really hope that we do get another version of SPDisposeCheck that can analyse our .NET 4.5 SharePoint 2013 code to stop developers out there from shoot themselves in the foot and taking down SharePoint servers with memory leaks.