Seen any Microsoft produced code that doesn’t pass Code Analysis/FxCop? [David Kean]

As some of you may already know, the majority of the Developer Division is currently planning features to be included in the next version of Visual Studio (Orcas). As part of this planning phase, the Managed Code Analysis (FxCop) team is beginning to work with other teams around Microsoft to ensure that any customer facing code released in Orcas is Code Analysis clean.
We’re also asking for your help. If you’ve ever come across code that hasn’t passed Code Analysis whether that be generated by custom tools, compilers, MSDN Library examples, sample applications, templates, designers, articles or any other Microsoft produced code, we want to hear about it.

Blog about it, tell your colleagues, managers, friends, spouses (if they write code), mailing lists, forums and any other medium that you can think of that if they have ever come across code that made them say ‘Damn Microsoft, I wish they would follow their own guidelines’ – then the Code Analysis team wants to hear from them.

As an example of what kind of issues we are looking for, see the following Product Feedback Center bugs:

Prevent generated DSL code from producing FxCop warnings
Windows Service template Dispose method does not pass FxCop analysis
AssemblyInfo to be FxCop compliant by default
“exception” expansion code sniplet has incorrect “public” visibility for serialisation contructor. FxCop rule violation

You can either post your feedback via a comment below or by using this blog’s contact form.

Comments (16)

  1. Aaron says:

    FxCop doesn’t pass fxcop 😛

  2. John Bledsoe says:

    This case may be the kind of thing that you’re looking for, and it relates to FxCop, so it seems like a fit.

    I have a class that has a DbDataAdapter as a public property. Per the MSDN Property Naming Guidelines, I gave the property the same name as its underlying type, DbDataAdapter. However, when I run FxCop against my class library, it gives me a SortAcronymsShouldBeUppercase warning, saying that I should call the property DBDataAdapter (uppercase "B"). Of course I won’t do that, since that would make my property definition:

    public DbDataAdapter DBDataAdapter { . . . }

    The information in the message even states:

    "For example, ‘DbConnection’, is common but incorrect; use DBConnection."

    Common? I’ll say! It’s baked right into the framework! In any case, I ignored the message and wasn’t really concerned, but since you’re asking, here you go!

  3. davkean says:

    Aaron: As part of our checkin tests we actually have to be clean on FxCop. The only assembly as it stands in 1.35 that doesn’t pass is Microsoft.Cci.dll, which is owned by another team, however, this will be clean in future versions.

    John: This is by design. The System.Data team got it wrong. However, for consistancy, you may choose to suppress it.

  4. The Managed Code Analysis (FxCop) team are working with other teams around Microsoft to ensure that…

  5. Obiwan Jacobi says:

    I like FxCop to recognize the construct of having an internal Guard/Check class to validate incoming method parameters. If I have code like:

    public void Method(string name)


     Guard.ThrowIfArgumentNull(name, "name");

     // use the name parameter here


    the current FxCop (vs2005) says I need to check the parameter of the public method (which is great).

    I would like to be able to tell FxCop how I’ve taken care of parameter checking in my app; maybe have a FxCop code Attribute (similar to the SuppressMessageAttribute) that marks my class (Guard) or method (ThrowIfArgumentNull) as an implementation of one of the rules.

    That would be great 😉


    Marc Jacobi

  6. A rule in FxCop says that static methods on a Generic class should be avoided with no exceptions due to the way that method gets called. That’s just wrong.

    I have a Generic base class like this:

    public abstract class Foo<T>

    With a static method like this:

    public static T Load(T instance, Guid id)

    FxCop gives me an error on the static method because when you call it, you have to declare the T-type. That is not the case. Here’s how it is called:

    FooBar f = FooBar.Load(instance, id)

    The rule simply isn’t true in this scenario and should be changed.

  7. asdfasdf says:

    when you run xsd on the xml schema for reporting services at the output is not clean

  8. Sri says:

    FxCop 1.32

    FxCop Build 50628.0

    Example code from

    Override methods on comparable types

    public static bool operator == (RatingInformation r1, RatingInformation r2)


            return r1.Equals(r2);


    Will throw


  9. seanf says:

    The following wizard generated code has many CA warnings:

    1) Create a new Visual Studio AddIn.

    2) Create a new WCF service reference.

    Using VS 2005 with WinFX Feb CTP.

  10. Jonathan Allen says:

    The vb code snippit for a new exception class inherits from ApplicationException instead of Exception.

  11. Sri says:


    Create a new web app.

    Default Global.asax.cs generated doesn’t pass code analysis.

  12. Amit Weisman says:

    Hi ,

    I was reading this article "Exception Management Architecture Guide” ( and stumbled across two issues :

    1. The example code violates this rule ( , page 9 , the parameter “info” is not checked.

    2. There is a clash between this rule ( and the purpose of the applicationexception class as described in this article. If I understood correctly this class supposed to be the base class for all the specific application exceptions, so the violating the rule is a “must”.


    I’m using fxcop and enjoying it.


  13. GBtG says:

    This came up in our development recently.  In VB.NET (under VS.NET 2003), follow these steps:

    1) Create a class that inherits from a Framework class (e.g. System.Web.UI.Control).

    2) Add some read-write properties.  Notice that the "Value" parameter of the "Set" portion of the property starts with an upper-case "V".  Violation of CA1709, although FxCop doesn’t seem to care…

    3) Now override an existing read-write property on the base class (e.g. Control.Visible).  Again notice the incorrect casing of the "Set" portion of the property.

    4) FxCop reports a violation of CA1725 for "renaming" the "value" parameter of the base-class property.

  14. davkean says:

    GBtG: The first issue is by-design, we ignore the casing of property parameters because no one actually sees the parameter.

    The second issue has been resolved in the latest build of FxCop.

    Thanks for the great feedback!