In Source Suppression Overview

After reviewing the code, you might determine that the code is correct as is. Or, it might be the case that some violations are of low priority and will not get fixed in the current development cycle. Regardless of the reason, it is often useful to indicate that the warning is non-applicable in order to let the team members know that the code was reviewed and it was determined that the warning be suppressed. In Source Suppression (ISS) is useful because it allows a developer to place the decoration that suppresses the warning close to the warning itself.

• SuppressMessage Attribute

  In source suppressions are rendered by using a conditionally emitted managed code custom attribute named SuppressMessage. This attribute has the following components:

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

  • Rule Category: The category in which the rule is defined.

  • Rule Id: The identifier for the rule. Support includes both a short and long name for the rule id. The short name is CAXXXX; the long name is CAXXXX:FriendlyTypeName.

  • Justification: The text 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

  • Parameter

  • Target: An identifier used to specify the target on which the warning is being suppressed.

• Usage

  In the common case, violations are suppressed at the level to which an instance of the SuppressMessage attribute is applied. The general form of suppression includes the rule category and a rule identifier which contains an optional human-readable representation of the rule name. This is preferred over source comments documenting the rule name, in order to make sure that information is tightly-coupled to exclusion. For example,

  [SuppressMessage("Microsoft.Design", "CA1039:ListsAreStrongTyped")]

  If there are stringent performance reasons for minimizing ISS metadata, the rule name itself can be left out. The rule category and its 'rule id' together constitute a sufficient unique rule identifier. For example,

  [SuppressMessage("Microsoft.Design", "CA1039")]

  This format is not recommended because of maintainability issues.

• Suppressing Multiple Violations within a method body

  Attributes can only be applied to a method and cannot be embedded within the method body. However, you can specify the identifier as the message id to distinguish multiple occurrences of a violation within a method.

  using System;
  namespace ClassLibrary1
  {
      public class Class1
      {
  [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA1806:DoNotIgnoreMethodResults", MessageId = "System.Guid")]
  
          public static bool IsValidGuid(string guid)
  
          {
           try
           {
            new Guid(guid); // Causes CA1806: DoNotIgnoreMethodResults
            return true;
           }
  
           catch (ArgumentNullException)
           {
              }
  
           catch (OverflowException)
           {
           }
           catch (FormatException)
           {
           }
          return false;
        }
      }
  }
  

• Module-Level Suppressions

  The managed code analysis tool examines SuppressMessage attributes that are applied at the assembly, module, type, member, or parameter level. It also fires violations against resources and namespaces. These violations must be applied at the module level and are scoped. For example, the following message suppresses a namespace violation:

  [module: SuppressMessage("Microsoft.Design", "CA1020:AvoidNamespacesWithFewTypes", Scope = "namespace", Target = "MyNamespace")]
  

  Any suppression can be expressed by specifying an explicit scope. These suppressions must live at the module level; however, you cannot specify member-level suppression by decorating a type. Module-level suppressions are the only way to suppress messages that refer to compiler-generated code that does not map to explicitly provided user source. For example, the following code suppresses violation against a compiler-emitted constructor:

  [module: SuppressMessage("Microsoft.Design", "CA1055:AbstractTypesDoNotHavePublicConstructors", Scope="member", Target="Microsoft.Tools.FxCop.Type..ctor()")]

  Note   Target always contains the fully-qualified item name.

• Global Suppression File

  Global suppression file maintains suppressions that do not have a target. For example, assembly level violations are stored in this file. Additionally, some ASP.NET suppressions are stored in this file because project level settings are not available for code behind form.

See Also

Reference

System.Diagnostics.CodeAnalysis