Suppressing Code Analysis Warning

This post is regarding suppressing few warnings while doing static code analysis for your project via tools such as FxCop.

A Bit of History

Yesterday, I was working at a few code modules wherein I was supposed to fix some FxCop warnings. While doing so, I had a few blockages while fixing few warnings, wherein those warnings fix changes that lead to minor and sometimes major design changes. Of course, it's a standard guideline that when you’re doing static code analysis (FxCop in this case), do not intend to change the design. I believe that this analysis phase is part of Refactoring.

But I wanted a way to escape from those warnings, of course one way is to customize the rule sets of FxCop tool. This is very easy, but at my work, everything is pre-configured rules for this tool and I am not supposed to change it, no matter what.

So I started to look for some other way to solve this problem. This post is just to share what I have learned on the same. Hope you will like it.

Let me start off by presenting a small code for which I am doing code analysis via FxCop.

So logically, there is no problem with the above code and yes, you sure will get few warnings in fxCop as shown in the below image:

Let's assume that I am supposed to fix the above shown warnings which are pretty commonly occurring ones for all but assume that those warnings may lead to design change or you’re not interested to fix it. As said earlier, if you had to remove those warnings in your code, but not supposed to change rule sets, then it's pretty tough. Thanks to SuppressMessage attribute provided by FCL.

So I added the below attribute code to the Main method as shown:

[SuppressMessage("Microsoft.Usage","CA1806",
Justification="I do not care to fix", Scope="Just for this method")]
publicstaticvoid Main()
{
for (int i = 0; i <5; i++)
{
str.Add(new Program());
new Program();
}
Console.ReadLine();
}

As you can see, SuppressMessage() attribute takes a couple of arguments. The first argument is the category of the warning which in this case you can get from the FxCop tool as shown in the below image:

The second argument is CheckID which again you can get from FxCop. Third onwards arguments are named parameters, where are optional. In the above code, I have written some justification statement for Justification parameter argument followed by the scope of this suppress attribute. You can also place this attribute for class, fields, properties, methods, etc. which is quite helpful actually.

Now once I make the above changes, FxCop will not show any changes in its output actually. This is because, we need to set Conditional Compilation Symbol to CODE_ANALYSIS in project properties as shown in the below image:

After making the above changes, compile the code and start over FxCop analysis. Now you shall notice that those warnings which you knocked off with SuppressMessage attribute will not be reported by FxCop tool. Please note that you need to do this only for Debug build and not for Release build.

Also there is something I also learned in this tool, i.e., FxCop that you can set the target framework for the specifics extra rules set check to just make sure there is no non targeted framework API gets included.

What I mean is when a user selects .NET Framework 3.0 as their project’s target framework, FxCop will fire on any usage of members and types that were introduced in .NET Framework 2.0 SP1 and SP2, etc. This is because on a fresh install of .NET Framework 3.0 in an OS, none of these service packs or frameworks are installed.

Some real world examples, the nice pare it you can have a long description, linked to a short name, and intellisense will even display your desciption in a mouse over... How great is that?

///<summary>/// Justifications for suppressions.
///</summary>publicstaticclass Justifications
{
///<summary>/// The analyzer thinks this class is not used, but it is not parsing the Linq Expressions very well.
///</summary>publicconststring ImplictlyCreatedInLinqExpression = "The analyzer thinks this class is not used, but it is not parsing the Linq Expressions very well.";
///<summary>/// Rule CA1006:
/// WSDL does not have generics. The class will be described as "X_of_y".
/// There is no way to call this method with a generic parameter,
/// which to me counts as a justification to suppress the rule.
///</summary>publicconststring NoGenericsOnWebservice = "This is a web method, the generics will be hidden.";
///<summary>/// This value is reserved for future use. We understand that this practice is frowned upon,
/// However we feel that we really need to do this for this value.
///</summary>publicconststring ReservedForFutureUse = "Not yet it isn't.";
///<summary>/// It's a good suggestion, however this class is publicly visible and already in use.
/// We can not change this without breaking 3rd party software.
///</summary>publicconststring ThatWouldBeABreakingChange = "It's a good suggestion, but we can't";
///<summary>/// Required for proper WSDL generation.
/// Without this the wsdl becomes either unsuable or the generated class names become too long to be funny.
///</summary>publicconststring RequiredForWsdlGeneration = "Required for proper WSDL generation";