Getting started with the SPDisposeCheck activity
[New for Release 1.3.0.0]
The SPDisposeCheck activity can be used to run the SPDisposeCheck.exe tool to check for coding best practices in SharePoint 2010 assemblies. For more details on this tool see the SharePoint Dispose Checker site. In this example we aim to show the basic steps that are required to get the activity integrated into a build.
If you are working with 2013 you may also wish to look at SPCop. This tool supports both SharePoint 2010 and 2013. It is the open source part of the SharePoint Code Analysis Framework which includes TFS build features
Note: That SPDisposeChecker, like any other command line tools, can be integrated with TFS build using the InvokeMethod activity. This activity custom provides no new features over a direct call using InvokeMethod. However, it does wrapper the command in a hopefully easier to use way.
Before you can make use of any of the TFS community build activities you have to make sure they are available for the build system and on your development PC. Instructions for this process can be found in the ALM Rangers build guide or in the getting started page of this wiki. This page assumes the SPDisposeCheck activity is available in the developers build process workflow toolbox.
The current version of the SPDisposeCheker can be downloaded from the SharePoint Dispose Checker site. This needs to be installed on the build agent PC.
The SPDisposeChecker activity should added to the workflow. As the tool works with compiled assemblies it is probably best to place it just after the build workflows Compile and Tests block.
The following properties need to be set (as a minimum)
| Parameter | Value |
|---|---|
| AssemblyDirectory | (Required) – this folder to check for assemblies to scan. You don’t have to worry about selecting only SharePoint assemblies. If you try to scan a non SharePoint assemblies the tool will just find no issues. So a good starting option is to just use outputDirectory. |
| LogFile | This is folder to dump the analysis results in. A good default is BuildDetail.DropLocation as this places the report file in the build drop location which can be accessed by all |
| SPDisposePath | The activity will try to look for the command line exe in it’s default location. If this fails a hard coded path can be entered in this property e.g. "C:\Program Files (x86)\Microsoft\SharePoint Dispose Check\SPDisposeCheck.exe" |
When the build is run, and if a SPDispose violation is found, then the build will fail and the number of issues will be listed in the build report summary. The details of the issues will be found in the report file in the drops location (if using the setting above)
The activity also returns an out bool parameter AnalysisFailed to indicated if any issues were found, which can be used in the build workflow.
