Chapter 8. Writing Code Analysis Rules
If you couldn't tell from my excitement in discussing the Code Analysis applications in the "Always Build with Code Analysis Turned On" section of Chapter 2, "Preparing for Debugging," I think Code Analysis, and the stand-alone version, FxCop, are two of the most exciting parts of .NET development. As soon as I saw the original version of FxCop, I immediately had to know how to add my own rules to the mix. Fortunately, it's not as hard as you might think, as you'll learn in this chapter. If you skipped over the discussion of Code Analysis in Chapter 2, I strongly suggest that you read it before reading this chapter. That section discusses the reasons why Code Analysis is so important and why you'll want to turn it on for all your builds. Additionally, it discusses all the custom rules that I provided from a usage standpoint. This chapter is all about gory details necessary to writing the rules, and I assume that you've already read that section in Chapter 2. Before we jump into the details of writing rules, I have to make a major hacking alert. Microsoft has never documented how to write rules, so I've had to perform the magic of reverse engineering to figure out how to create rules. Fortunately, given Reflector's amazing decompiling abilities, it's mainly a matter of just reading through all the rules provided with Code Analysis. Also, the FxCop Team, who's responsible for Code Analysis and provides the stand-alone version, FxCop, has stated publicly multiple times that they are working on a complete new engine for static analysis for future versions of Microsoft Visual Studio. That engine will be bigger and better, and will break backwards compatibility with the existing engine. The good news is that the FxCop team has said that they will finally document the new engine for rule writers. Even with those warnings, the good news is that Visual Studio 2005 will be around awhile, so investing in any custom rules will definitely pay for themselves the first time they find a bug. Because I use all of these rules every day, I have a stake in keeping them up to date with any changes Microsoft makes to the rules engine. Check the book's update site, http://dtt.wintellect.com, for the latest information about all the Code Analysis rules discussed in this chapter and in the book's source code. The rules I discuss in this chapter work both with Code Analysis built into the Visual Studio 2005 Team Suite Edition and Team Developer Edition in addition to the stand-alone FxCop available at (http://www.gotdotnet.com/team/FxCop/). That way you can benefit no matter which version of Visual Studio you are using. Because Code Analysis and FxCop are two different versions, there's no way to use a single rule with both. All of my rules are built to run with FxCop 1.35, which was the latest version available when I wrote this book. One other point I need to make before we jump into rule development is that some of the rules I developed in this chapter rely on analyzing the Intermediate Language (IL) code generated by the compiler. Since virtually all of .NET development is done with either C# or Visual Basic, I worried only about those two compilers. If other languages start becoming more popular, I'll update the rules to account for those languages. |
EAN: 2147483647
Pages: 99