Share via

Writing Custom Rules in FxCop & FxCop Visual Studio Integration [Jeffrey van Gogh]

  • Article

Two common questions we often get are:

  • Can I write my own rules for FxCop and customize existing rules?
  • Can I integrate FxCop into visual studio and can I jump to the location in my source of the item that FxCop flags as an error?

 That's why I want to give some more information on both:

FxCop supports writing custom rules. Custom Rules can be written by writing a class in any.NET language. This class has to implement one of the interfaces FxCop provides via its SDK. After compiling the class into an assembly, FxCop can load the custom rule by pointing it to that assembly. Samples and Documentation on how to do this can be found on our webpage:

the SDK Documentation: https://www.gotdotnet.com/team/fxcop/docs/gotdotnetstyle.aspx?url=UsingFxCopSdk.htm

the Samples: https://www.gotdotnet.com/team/fxcop/docs/SDKSamples.zip

FxCop doesn’t really support editing the default rules right now. We are making some rules configurable for our next release, e.g. you can change settings of the spelling rules and you can change on which members the Naming rules run (by default they run only on members visible outside of the assembly).

FxCop integrates into VS.NET as an external tool using the Commandline version of FxCop. On details how to do this, see https://www.gotdotnet.com/team/fxcop/docs/UsingFxCopCmd.htm#_Visual_Studio_Integration

FxCop is able to find sourcecode location for an error message if both following conditions are met:

  • The compiler emitted a .pdb file for the assembly (/debug+ switch for C# Compiler, enabled by default in VS)
  • The error message occurs in an executable piece of code inside the assembly (assembly, namespace, type, field & attribute error messages are not in executable code and the compiler therefore doesn’t generate source lookup information)

In the upcoming release of FxCop, with our new Metadata reader, we will be able to do a much better job for jumping to source code. Currently FxCop jumps to the first line of a method in which an FxCop issue is found. In the next version of FxCop we will jump to the exact line of code that has an issue.

Comments

  • Anonymous
    January 09, 2004
    I love this FxCop, but why does it complain about so much code that visual studio generates in a web project?

    I can get my class libraries down to no problems, but for an asp web app, I have to exclude a lot of things.

    Is is hard to separate VS.Net protected controls in code behind from one that should be fixed

  • Anonymous
    January 10, 2004
    Andrew, the issues with FxCop firing on ASP.NET generated code should all be resolved in our next major release.

    Thanks for using FxCop!

    Nicholas Guerrera
    FxCop Team
  • Anonymous
    January 10, 2004
    The comment has been removed
  • Anonymous
    July 27, 2004
    Hi, although I can navigate to source code from the standard rules messages i cannot do the same for custom rules (see output below). Is there any workaround?

    Regards, Allen

    Information : ParameterNamingConventionViolated : windowsapplication1.dll, WindowsApplication1.Form1.Dispose(System.Boolean)#System.Void.!Parameter[0] : 'disposing' should follow naming convention.

    d:workvsnetprojectswindowsapplication1form1.cs(62) : Warning : AvoidBuildingNonCallableCode : windowsapplication1.dll, WindowsApplication1.Form1.Main()#System.Void : 'WindowsApplication1.Form1.Main' appears to have no upstream public or protected callers.