Run SPDisposeCheck as Build Task and Automated Unit Test

SPDisposeCheck is a valuable tool devloped by a small team within Microsoft Premier Support led by Roger Lamb that inspects an assembly to ensure that SharePoint API objects are properly disposed. Failure to properly dispose SharePoint API objects can cause memory leaks. The SPDisposeCheck tool can be downloaded here:

 http://download.microsoft.com/download/B/4/D/B4D279A0-E159-40BF-A5E8-F49ABDBE95C7/SPDisposeCheck.msi

 Running SPDisposeCheck has always been a manual procedure that a SharePoint architect or team lead has to make sure is run against all new code before a release; or worse run afterward in order to find a leak that is already in production. A preferable approach would be to add this to a unit test that can be part of a restrictive check-in policy in TFS to ensure no code, in which SharePoint API objects are not properly disposed, can be checked in. Here is how that can be accomplished:

 Copy the SharePoint Dispose Check folder as a sub folder of the solution folder as demonstrated below:

 

 
 Find all projects under the solution that reference the Microsoft.SharePoint namespace and select properties on the project file. Select the Build Events tab and enter the commands below into the Post-build events text box for On Successful Build:

 cd $(ProjectDir)

“..\SharePoint Dispose Check\SPDisposeCheck” “$(TargetPath)” > “$(ProjectName)”.SPDisposeCheck.log

findstr /C:”Total Found:” “$(ProjectName)”.SPDisposeCheck.log

 The Post-build events above will run the SPDisposeCheck tool against the compiled assembly outputting to a file that consists of the assembly name appended with .SPDisposeCheck.log. When the project is compiled the developer will see in the output window “Total Found: X” where X is the count of SPDisposeCheck errors in the assembly. See below:

 

 Any value other than “Total Found: 0″ means that a SPDisposeCheck error has been spotted. This is a good start, as developers can be instructed to look for this value but not good enough because it’s too easy to ignore. The next step would be to add this to a unit test which can be tied to a TFS restricted check in policy which cannot be ignored. To do this open the class file right click the class and select “Create Unit Tests”

 

 Add a new unit test to the automatically generated unit tests as seen below: The text specified in the File.OpenText section should be replaced with the name of the assembly in question.


///
///A test to ensure SharePoint objects are properly disposed
///
[TestMethod()]
public void SPDisposeCheckTest()
{
     StreamReader streamReader = File.OpenText(@"..\..\..\Intellinet.SharePoint.Utility\Intellinet.SharePoint.Utility.SPDisposeCheck.log");
     String logFile = streamReader.ReadToEnd();
     Assert.IsTrue(logFile.Contains("Total Found: 0"), logFile);
}


This unit test will fail if the file generated by SPDisposeCheck has any value other than “Total Found: 0″ and the contents of the file including the links to Roger’s examples of correcting the particular type of dispose defect can be viewed by the developer by clicking the failed unit test.

Since SPDisposeCheck is performing static analysis on the IL a better approach would be to reverse the SPDisposeCheck code and create a Static Analysis rule that would be available as one of the Static Analysis rulesets in TFS. Until that day this can be a very useful approach for SharePoint architects to control code quality and prevent SharePoint API dispose memory leaks.

About these ads