Let’s talk about FxCop first. Or actually the FxCops as there are two of them:
- C:\Program Files (x86)\Microsoft FxCop 1.36\FxCop.exe
- C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop\FxCop.exe
The first one was the so called stand-alone version which you would install on a build server. The second one is integrated in Visual Studio – even the Express versions. It runs when you click “Run Code Analysis” on the Analyze menu in Visual Studio.
There are even more versions of FxCop but let’s focus on those two and their SharePoint angle.
FxCop’s SharePoint Angle
FxCop is extensible and the “SharePoint FxCop Rules” are an additional set of SharePoint specific FxCop rules like “SP0001 – Dispose created SPSite or SPWeb objects”.
They did a good job until we decided to use the integrated version of FxCop exclusively. The reason was that we wanted our Continuous Build server to report the same FxCop issues as Visual Studio’s analysis (*).
Switching to that version of FxCop resulted in error 536 – FxCop couldn’t find an analysis DLL or one of it’s dependencies. Fusion Log Viewer showed that SharePoint.FxCop.BestPracticesRules.dll references FxCopSdk.dll, Version=220.127.116.11 but found Version=10.0.0.0. And shure enough that was the integrated FxCop’s DLL while the older one came with the stand alone version.
The solution would be a binding reference redirect or a build of SharePoint.FxCop.BestPracticesRules.dll referencing the updated FxCopSdk.dll. Also more recent developments like the “SharePoint Code Analysis Framework (SPCAF)” come to mind.
*: yes, we finally installed Visual Studio on the build server. That was after copying various assemblies and MSBuild targets and still failing to get the SharePoint solution to build on it. Customers prefer lower cost over technical excellence.