Posts Tagged FxCop

Compiling static analysis rules targeting both FxCop and Visual Studio

Posted by claudiolassala in Software Development on June 27, 2007

We have a bunch of custom static analysis rules that we wrote here at the company. We have to make them available for use with both FxCop (the stand-alone tool) and Visual Studio (the Team System edition that supports code analysis). In order to support the rules in both scenarios, they must be built against the specific APIs (either the FxCop or the Visual Studio versions). That means when I build the rules, I need to make sure I add references to the right assemblies. To facilitate this, I’ve changed the MSBuild files to pull in the right references depending on what build configuration I’m using.

The main assemblies we needed imported are the FxCopSdk.dll and the Microsoft.Cci.dll. The FxCop versions reside under the FxCop installation folder (something like c:\Program Files\Microsoft FxCop 1.35), and the Visual Studio version resides under the VS installation folder (something like C:\program files\microsoft visual studio 8\team tools\static analysis tools\fxcop\).

First thing I did was to create a new MSBuild project file, named FxCopReferences.proj. The content of this file is listed below:

<Project DefaultTargets="Build" 
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Reference Condition=" '$(Configuration)' == 'Debug' " 
          Include="FxCopSdk, Version=1.35.0.0, Culture=neutral, 
          PublicKeyToken=2725db9ba1c53c87, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>
         ..\..\..\..\..\..\Program Files\Microsoft FxCop 1.35\FxCopSdk.dll
      </HintPath>
    </Reference>
    <Reference Condition=" '$(Configuration)' == 'Debug' " 
          Include="Microsoft.Cci, Version=1.35.0.0, Culture=neutral, 
          PublicKeyToken=2725db9ba1c53c87, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>
         ..\..\..\..\..\..\Program Files\Microsoft FxCop 1.35\Microsoft.Cci.DLL
      </HintPath>
    </Reference>

    <Reference Condition=" '$(Configuration)' == 'Release' " 
          Include="FxCopSdk, Version=8.0.0.0, Culture=neutral, 
          PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>
         ..\..\..\..\..\..\Program Files\Microsoft Visual Studio 8\
         Team Tools\Static Analysis Tools\FxCop\FxCopSdk.dll
      </HintPath>
    </Reference>
    <Reference Condition=" '$(Configuration)' == 'Release' " 
          Include="Microsoft.Cci, Version=8.0.0.0, Culture=neutral, 
          PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>
         ..\..\..\..\..\..\Program Files\Microsoft Visual Studio 8\
         Team Tools\Static Analysis Tools\FxCop\Microsoft.Cci.dll
      </HintPath>
    </Reference>
  </ItemGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
</Project>

The MSBuild project above defines an ItemGroup with Reference elements. The reference elements use the Condition to determine what kind of Build Configuration is being used: if "Debug", build it to FxCop; if "Release", build it to Visual Studio. Eventually I’ll change that to have FxCop and VS build configurations, but for now, I’m just going with that.

Next, I removed the references to the assemblies that I had before from my rule projects, and changed the project file (csproj file), so that it imports the FxCopReferences.proj file. That means I just added the following line to my csproj files:  

<Import Project="..\..\StaticAnalysisRules\FxCopReferences.proj" />

That’s it! This approach gives me a quick way to produce versions of our rules assemblies targeting different code analysis runners (FxCop or Visual Studio, that is).

Leave a comment

Migration FxCop custom rules to work with .NET 2.0

Posted by claudiolassala in Software Development, Uncategorized on March 17, 2006

I’ve had a bunch of libraries of custom rules that we’ve been using with FxCop against .NET 1.x code. I’ve just gone through the process of recompiling those rules to work against .NET 2.0 assemblies, both using VS 2005 integration with code analysis and the external FxCop 1.35 GUI. Here are my findings on the process:
 
  1. I didn’t have to anything on the code for the rules (seems like the introspection engine hasn’t changed).
  2. In order to use the custom rules within the VS 2005 IDE, the rule assemblies must be copied under the following directory: C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\Rules.
  3. Note that if you’re using the rules within VS 2005, the rule assembly must be compiled against the FxCopSdk.dll and Microsoft.Cci.dll that come with VS 2005 (they’re under C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\). If you’re using the rules from FxCop external GUI instead, the rule assemblies must be compiled against FxCopSdk.dll and Microsoft.Cci.dll that come with FxCop (under some folder like this: C:\Program Files\Microsoft FxCop 1.35).

At this point, I might say I like the integration of code analysis into the VS IDE. However, I still like the way FxCop GUI displays the violations better (better way to see information about the violations, as well as notes typed in by the developers).

See more on the differences between FxCop and VS 2005 on the following posts:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=300185&SiteID=1

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=299899&SiteID=1

Leave a comment