Run MSOCAF in Visual Studio and on the build server
UPDATE (1st of November 2011):
I've since uploaded the re-targetted MSOCAF rules to CodePlex and I've applied a few fixes to prevent CodeAnalysis from crashing under certain conditions. They're not part of any official release, but if you just download the solution and build it, you should be on your way. To build these rules you need to have the following items installed: Visual Studio 2010 with Code Analysis, ILMerge and the latest stable version of the MsBuild Community Tasks.
When building, there is a compiler directive which either builds the code to integrate deeply into Visual Studio and will allow you to suppress warnings inline. Or you can define the ORIGINAL constant to build the code to work exactly like the wizard would, allowing you to suppress messages in both Visual Studio (global suppressions only) and the MSOCAF wizard.
Anyone who has previously worked with SharePoint Online, has had to go through the MSOCAF verification tools. On my current project, it is also required to run these checks against every SharePoint project before they're actually released to an Integration environment.
MSOCAF is a pretty tool. Meaning it looks nice ;). Under the hood it is just a collection of tools that were available to developers.
And it brings a few additional FxCop rules that have been written to check for a lot of SharePoint code smells.
You can download and run MSOCAF if you want, you can also download the individual tools and run them manually, but whet I really wanted was a way to integrate these checks in our build with the least amount of effort and the highest amount of developer satisfactory.
Option 1
Install all these tools on the dev machines, and configure them to run after each build either through the built-in options or through post build steps.
Pros
- Works by default
Cons
- Requires these tools to be set up on every machine
- Uses a different mechanism for each tool
- Doesn't integrate with msbuild directly so it won't run on the buildserver
- Doesn't integrate with the standard Supression options for Code Analysis
Option 2
Create MsBuild targets for each of these tools, change the project files to execute these targets along with the build
Pros
- Integrates with the buildserver
Cons
- Requires these tools to be set up on every machine
- Requires changes to the build files
- Doesn't integrate with the standard Supression options for Code Analysis
- Not well understood by most developers
Option 3
So I opted for option 3. Ignore CAT .Net 1.1 (it's old anyway) and build/port Visual Studio 2010 Code Analysis rules for the other tools.
Pros
- Integrates with the build server
- Requires only a few dlls to be dropped in a central location
- Integrates with the standard Suppression options for Code Analysis inside Visual Studio
- Easy to enforce rules through Check-in policies in TFS
Cons
- Requires custom code
- FxCop custom rules weren't written for FxCop 10 (which comes with Visual Studio 2010) but for FxCop 1.36.
So I ended up writing a wrapper for SPDisposeChecker. There already is one available on codeplex, but that executes SPDisposeChecker as a separate process and parses the output, breaking Visual Studio suppression options. Instead I created a small wrapper which loads the actual class that does the checking through reflection (it's marked internal) and I created a Code Analysis rule which links the actual statements to the errors which were found. It isn't the most optimal way of doing this (essentially this parses the assembly twice), but it does give the best integration with Visual Studio with the least amount of work.
The MSOCAF custom rules were a whole different kind of ballgame. These rules were written for FxCop 1.36 and as such cannot be used in FxCop 10 (different framework requirements, small changes to FxCop itself). So to get these to work I had to get access to the sources (which unfortunately aren't available as far as I know). So I installed the File Generator plugin for .NET Reflector, generated a Visual Studio project for the assembly and tried to compile. No such luck...
Turns out that I had to change the references for my project after importing them into Visual Studio (sounds logical)... But while trying to add the FxCopSDK, CCI and CodeAnalysis assemblies I got an error telling me that I was targeting the wrong Framework version. So I changed the framework version to 3.5, added the references and tried to compile yet again. New error, basically telling em that I needed to compile against 4.0 (huh?!)... So I changed the framework version back to 4.0, but now with the references in place and Visual Studio didn't bug me about the framework version any longer.
What it did bug me with, was a large list of build errors. Some very logical (types that had moved from one namespace to another), some that were due to strange compiler generated type names (containing <> $ and other funny characters)... So after doing a search and replace for these characters and changing them all to _, I got a few errors about missing types. Turns out that the compiler does some fancy stuff when compiling anonymous delegates and that .NET Reflector 6.8 doesn't handle these cases correctly. After manually changing the offending code and copying some compiler generated code which the File Generator plugin had omitted, things suddenly started working.
I didn't end up rebuilding CAT.NET 1.1, as it is a lot more extensive. There are a few posts on how to create your own MsBuild tasks to run it, but it's also very easy to change the add-in (which was originally built for Visual Studio 2005 and 2008) to work on Visual Studio 2010. This doesn't integrate into Visual Studio as tightly as you might want, and I've had a few issues with 32bit/64bit versions of CAT.NET and MsBuild.
Also, check out AntAlpha's post on how to suppress CAT.NET Messages in code.
The end result is that I now have 3 assemblies to deploy to my developer machines, that I can run the all of the important checks directly form the developers machines and in the integrated build and that I have a very high level of Visual Studio integration with regards to suppressions.
(images to follow)