John Robbins' Blog

VS 2010 Beta 2 Code Analysis In-Depth First Look

Code Analysis is one of those great tools that people don't run nearly enough. I have screamed repeatedly, "Never do anything at run time you can do at compile time." The best time to catch the Design Guidelines, security, and performance violations is at build time. Code Analysis and its standalone twin, FxCop, have been around long enough that I shouldn't have to convince anyone that every single build, no matter who does it, must have Code Analysis running.

If you start using Code Analysis from day one, it's easy, but sadly, many teams have not. Recently, I wrote an article talking about how to introduce Code Analysis and FxCop on Visual Studio 2008 projects without getting overwhelmed. For Visual Studio 2010, Microsoft has added a great feature to Code Analysis called Rule Sets, where you can create subsets of the rules you're most interested in running. The estimable Habib Heydarian wrote an article that shows you everything you need to know about creating and manipulating rule set files.

With Beta 2, I was hoping Microsoft was going to fix a large bug pertaining to Code Analysis. The bad news is that it wasn't. No new projects created in Visual Studio 2010 have Code Analysis enabled by default. That's frustrating because Code Analysis uses a default Rule Set "Minimum Recommended Rules" whose rule set description says it all, "These rules focus on the most critical problems in your code, including potential security holes, application crashes, and other important logic and design errors." Yes, I will be logging this as a bug because positive nudges like this are an extremely cheap and easy way to avoid bugs.

With Visual Studio Beta 2 being essentially feature complete, I was very curious to see the new rules that Microsoft has added to Code Analysis. Here's the list I compiled by comparing Code Analysis from Visual Studio 2008 to that in Visual Studio 2010. Note that some of these links to the rule documentation go to pages that do not yet exist on the MSDN web site as of this writing. I pulled the help URLs for the rules out of the assembly resources so they will eventually be valid.

Microsoft Design

Microsoft Globalization

Microsoft Naming

Microsoft Reliability

Microsoft Security

Microsoft Usage

Interestingly, I noticed the following rules are no longer alive in Visual Studio 2010. May they rest in peace.

Microsoft Security

Probably the most interesting thing about Code Analysis in Visual Studio 2010 is that Microsoft has reintroduced the dataflow analysis. Back in the early versions of FxCop there was a dataflow analysis engine but it was scrapped and a new engine has taken its place.

Many of the new rules, such as CA 1062 – Validate arguments of public methods utilize the new engine. If you're super curious, you can use Reflector to poke around the dataflow rules by opening the DataFlowRules.DLL assembly in <Visual Studio Directory>\Team Tools\Static Analysis\FxCop\Rules. Without documentation and a simple example, it's hard to see how it all works. However, poking around through the dataflow engine supporting assemblies, you will come across PHX.DLL.

At one point Microsoft was working on a compiler framework called Phoenix, which was going to be used to build a pluggable compiler system. The idea was that if someone had an idea for an analysis or optimization tool they could plug into the compiler chain or rewrite the Intermediate Representation (IR) and add their additional analysis or optimizations. While there's a vibrant research community built around Phoenix, I don't know where it stands on the product side. However, as I poked around PHX.DLL, it wasn't too much of a stretch to see that I was looking at a version of the Phoenix code. Namespaces like Phx.Pdb, Phx.PE, and Phx.LoopOptimizer aren't the typical namespaces used in a SilverLight line of business application.

For more traditional rules, such as CA1714 – Flags enums should have plural names, they still use the Introspection engine first introduced in FxCop 1.30. That means if you've already written rules for FxCop they will port right over to Visual Studio 2010's Code Analysis without much trouble.

Code Analysis is one of those tools that just sits there quietly doing its job and if you run it on every compile, you never see just how valuable it really is. Catching errors as early as possible in the development cycle is what saves you the big time and money. Nothing annoys me more that when I hear someone say that they don't run Code Analysis because they don't have the time, or because Code Analysis is to slow, or any other of a million lame excuses. Oh, let me take that back. Actually, I when I hear people say any reason they don't run Code Analysis on every build, I rub my hands with delightful glee because I know that Wintellect will be getting a huge contract soon from them to debug or take over developing their application.

OK, let me get serious: Microsoft runs Code Analysis on everything and so should you. That's what great companies do and the Code Analysis in Visual Studio 2010 with its rule sets makes it even easier to do. You no longer have any excuses.

On Oct 19 2009 8:26 AMBy jrobbins With 11 Comments

Comments (11)

  1. What's the state of play with static code analysis (?Prefast?) for native C++ code in VS2010?

  2. Hi Mike!

    I'm pretty sure PreFast has been added to the x64 compiler. I haven't seen much written about it but know that lots of people are using and improving PreFast at Microsoft so it should be improved, but by how much, I'm not sure. I'm going to be porting a bunch of C++ code over to VS 2010 and will blog about the experience. I'll specifically look at PreFast for you.

    - John Robbins

  3. I have found out the in order to fail your build when some code analysis rule fails you should do the following:
    1. Create and use a rule set in which all rule violations are treated as errors instead of warnings, or
    2. Use the CodeAnalysisTreatWarningsAsErrors build property (see http://blogs.msdn.com/fxcop/archive/2007/08/08/_24002800_CodeAnalysisTreatWarningAsErrors_2900_-MSBuild-property.aspx for details).

    regards,

  4. Ricardo Lopez

    When using contract methods such as Assert((c),(lambda)) where c is a condition and lamda is a Func one still gets CA1062.

    Is there a way to inform the code analysis engine that the Assert method has validated the argument?

    An example may be helpful to clarify my question:

    MethodA( String parameter)
    {
    Assert( (parameter != null), (() => new ArgumentNullExpetion("parameter")));

    If (parameter.length == 0) // CA1062 applies here
    {
    ...
    }
    }

    Thanks!

  5. Ricardo,

    The assert goes away in a release build so CA1062 is properly reporting that you haven't checked the parameter property before accessing it's field.

    - John Robbins

  6. We have been using code analysis in Visual Studio since VS 2005. When we upgraded to 2008, we noticed that our code had a lot of new code analysis complaints. Just this week, we upgraded to VS 2010 and are once again faced with a lot of new code analysis failures in our existing code that fully satisfied the 2008 code analysis rules. In one website alone, there were over 1500 new complaints.

    Does Microsoft have an official recommendation on how to handle existing code? What's the community standard? Do most developers/companies spend the time to change the existing code to satisfy code analysis or do most just suppress them in order to grandfather them into the new rules.

    Thanks for any advice you may have!

Leave a Comment

Archives

Tags