Thinking About Rule Development


Back in the old .NET 1.0 days, the original version of FxCop used standard Reflection to open the assembly under analysis and walk through the data in the assembly. Although that worked, we all know that Reflection is quite slow and locks the assembly, so you had to shut down FxCop every time you wanted to rebuild the assembly. The Reflection engine did a decent job of letting you access all parts of the compiled code, but all the IL code for a method was returned as a giant text string. That meant that to do deep analysis on code constructs, you had to write extreme regular expressions or possibly a full-blown IL parser. That severely limited rule development to essentially the FxCop team at Microsoft, who was being paid to write the rules.

After a few FxCop releases, the team rewrote the tool from scratch to remove the Reflection engine and switched to a new analysis engine called Introspection. The new engine did everything the Reflection engine did but didn't lock the assembly and was much, much faster. Additionally, it provided fantastic access to the underlying IL, so you no longer had to parse text buffers. The access is interesting in that either you can access the opcodes directly, or you can have the Introspection engine walk the IL for you.

Even better is that you get very cool support from the Introspection engine to access the call graph for callers and callees. You'll need just to make sure that the rule that you want makes sense from the standpoint of analyzing the binary. For example, if you are thinking about considering a performance analysis rule, unless you can look for an exact IL or call pattern, it might be better to use source analysis for that type of rule. A good example of a performance rule that works because you're looking for a fixed pattern is the TestForEmptyStringsUsingStringLength rule you'll find in PerformanceRules.dll.

When I first started looking at rule development, I couldn't quite get my head around what the Introspection engine was doing. After a while, it finally dawned on me that the way to think about it was that Introspection is just manual reflection. Whereas reflection loads up the assembly and calls the types and other information in the assembly, the Introspection engine maps the assembly into memory and goes through the grind of walking all the internal tables by hand. Interestingly, if you start looking hard at the Introspection engine with the Reflector tool, you'll see that through Introspection, it also supports creating code, much like the Reflection.Emit namespace.

The assemblies that provide the hooks for your rules to load into the Introspection engine are Microsoft.Cci.dll and FxCopSdk.dll, respectively. For building your rules with Code Analysis, you need to use the version in the Visual_Studio_2005_Install_Directory\Team Tools\Static Analysis Tools\FxCop, and for FxCop, you'll use the versions from the FxCop installation directory. If you're building your rules primarily for Code Analysis, you can fix your builds so your rules will compile no matter where the user has installed Visual Studio 2005. After you've added the references to the two assemblies, close the project and open the .VBProj/.CSProj file with either the XML editor or Notepad. Search for the Reference elements for Microsoft.Cci.dll and FxCopSdk.dll. In the HintPath element, replace the hard-coded path with the property $(FxCopDir), which MSBuild will expand to the appropriate path on the machine. The following shows a fixed-up Reference element:

    <Reference Include="FxCopSdk, Version=8.0.0.0, Culture=neutral,                PublicKeyToken=b03f5f7f11d50a3a,                processorArchitecture=MSIL">       <SpecificVersion>False</SpecificVersion>       <HintPath>$(FxCopDir)\FxCopSdk.dll</HintPath>       <Private>False</Private>     </Reference>


For more tricks about building for both Code Analysis and FxCop, see the FxCop team's blog at http://blogs.msdn.com/fxcop/.

Once you've built your rules, you need to load them. If you're using Code Analysis, the only place where rules are loaded from is Visual_Studio_2005_Install_Directory\Team Tools\Static Analysis Tools\FxCop\Rules. If you install the Code Analysis rules with WintellectToolsInstall.msi, my install takes care of putting the rules in the right location so they automatically show up as part of the Code Analysis page in Visual Studio 2005. For the stand-alone FxCop program, you add rules to the project by selecting Add Rules from the Project menu. The rules I built for FxCop are in the .\FxCop directory where you installed the book's source code. If you attempt to load the rules from the .\Debug or .\Release directory, which are built for Visual Studio 2005 Code Analysis, you will get exception error reports from FxCop.




Debugging Microsoft  .NET 2.0 Applications
Debugging Microsoft .NET 2.0 Applications
ISBN: 0735622027
EAN: 2147483647
Year: 2006
Pages: 99
Authors: John Robbins

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net