Performance Analysis: Disabling code-analysis warnings and Excluding Code Coverage for tested common methods

When the project in which I was working was going through performance analysis, we found our project has a lot of warning generated by code analysis and also code coverage is not up to mark. We analyze warning & methods that was not under test coverage. What we found was that we were mostly following best practices but still code analysis left us with a lot of warnings. Same goes with code-coverage, all new methods were having proper test cases for all scenarios. What’s wrong was happening???

Actual problem was :

1. Some code components (commonly used components and third-party code) developed earlier was considered tested and free from warnings, but that wasn’t the case.

2. Also we can’t change that code for warnings & test coverage (because nor time-constraint allows that neither we want to do so for ample many other reasons like copyright with change etc.)

So what can be solution.

Solution was nevertheless easier then we thought. Microsoft has provision for disabling code-analysis warnings & excluding code-coverage for such a scenarios only in System.Diagnostics.CodeAnalysis namespace.

NOTE: Although it’s not recommended to disable code-analysis warnings and also disabling code-coverage. Doing this can project wrong code-analysis data, but our scenario was just perfect for what Microsoft has provisioned disabling.

The System.Diagnostics.CodeAnalysis namespace contains classes for interaction with code analysis tools :

1. ExcludeFromCodeCoverageAttribute: Specifies that the attributed code should be excluded from code coverage information.

Actual working example

 public static OperationControl GetInstance()
   //Your code goes here

In above code, ExcludeFromCodeCoverage attribute will prevent the method from being covered in test coverage & thus increases code coverage percentage. Please note only third-party tested code, test methods and such cases are recommended for using the attribute & it must not be applied to all/most of methods that will defeat purpose of code-coverage check.

2. SuppressMessageAttribute: Suppresses reporting of a specific static analysis tool rule violation, allowing multiple suppressions on a single code artifact.

The SuppressMessage attribute has the following format:

[Scope:SuppressMessage("Rule Category", "Rule Id", Justification = "Justification", MessageId = "MessageId", Scope = "Scope", Target = "Target")]


  • Rule Category – The category in which the rule is defined. More information on categories can be found on msdn.
  • Rule Id – The identifier of the rule. Support includes both a short and long name for the rule identifier. The short name is CAXXXX; the long name is CAXXXX:FriendlyTypeName.
  • Justification – The text that is used to document the reason for suppressing the message.
  • Message Id – Unique identifier of a problem for each message.
  • Scope – The target on which the warning is being suppressed. If the target is not specified, it is set to the target of the attribute. Supported scopes include the following:
    • Module
    • Namespace
    • Resource
    • Type
    • Member
  • Target – An identifier that is used to specify the target on which the warning is being suppressed. It must contain a fully-qualified item name.

Actual working example

 public static OperationControl GetInstance()
   //Your code goes here

In above code SuppressMessage attribute will prevent Microsoft.Design warning”CA1024″.

For more detailed information you can refer following links on msdn: