Rule Metadata XML

Each rule assembly contains an XML resource defining metadata for all of the rules in the assembly. In Visual Studio, the addition of this resource to your project can be accomplished by adding an XML file and then marking the file as an "Embedded Resource" in the Visual Studio properties window.

<?xml version="1.0" encoding="utf-8"?>
<Rules FriendlyName="">
  <Rule TypeName="" Category="" CheckId="">
    <Name></Name>
    <Description></Description>
    <Url></Url>
    <Resolution></Resolution>
    <MessageLevel Certainty=""></MessageLevel>
    <Email></Email>
    <FixCategories></FixCategories>
    <Owner></Owner>
  </Rule>
</Rules>

The Rule tag may be repeated as many times as necessary. None of these tags should be interpreted as optional. In the event that a value is not required, the tag should still be present with its content left empty.

FriendlyName: The display name of the rule library as it will appear in the FxCop GUI rules tree.
TypeName: The name of the .NET class that implements the rule. Do not qualify with a namespace.
Category: The category of the rule. This should generally be a programmatic version of FriendlyName. It will typically be the same for all rules in the same assembly. The Category is important to end users when they declare exceptions to your rule (more on that later).
CheckId: An identifier that distinguishes the rule from all others in the same Category. Traditionally, this is two letters followed by a four digit number. Like Category, this is important when users declare exceptions to your rule.
Name: The display name of your rule as it will appear in the leaf level of the FxCop GUI rules tree.
Description: A description of your rule. Traditionally, these are detailed explanations providing background on why the rule exists and how users should go about remedying violations of the rule. FxCop will display these in the bottom panel of its GUI when a violation of the rule is highlighted.
Url: A URL associated with the rule that can be used to provide even more information about the rule than you would ordinarily include in the Description element. Url can be left empty if no URL is desired.
Resolution: A short suggestion on how to fix the violation. It may contain String.Format placeholders whose values are to be supplied programmatically by the rule when it detects the violation. FxCop will show the resolution to the user when the rule is violated. (Multiple resolutions for a rule may be specified if a Name attribute is included on the Resolution tag. The rule selects one of these resolutions when it detects the violation.)
MessageLevel: The severity of the error: CriticalError, Error, CriticalWarning, or Warning.
Certainty: The certainty is an integer from 0 to 100 that indicates how often the rule typically detects a real problem in the code. (Inversely, 100-certainty is how often the user will typically need to declare an exception to the rule.) This tag is purely informational.
Email: An email address to be associated with the rule for display to the user. Often left empty.
FixCategories: Characterizes the impact of fixing the rule: Breaking, NonBreaking, or DependsOnFix. This is purely informational.
Owner: The person who "owns" the rule for display to the user. Often left empty.

	Important
	Be sure to observe the proper element/attribute capitalization and structure when declaring your rules. If the XML is not formatted correctly, FxCop might not be able to load your rules. Often, FxCop will ignore rules without displaying any error messages. If this happens to you, carefully review the XML.

All classes in your custom rule assembly that implement IRule (typically by inheriting from BaseIntrospectionRule) must have a corresponding Rule tag that matches on TypeName.

	Note
	Rule classes do not need to be declared `public` because FxCop instantiates them using reflection.

Figure 5. Project With Rule Metadata XML Embedded Resource

Figure 6. Sample Metadata XML

<Rules FriendlyName="Tutorial Rules">
  <Rule TypeName="ClassFieldNamePrefixes" Category="Tutorial" CheckId="TT1010">
    <Name>Class field names should use the 'm_' and 'g_' suffixes.</Name>
    <Description>
      Instance fields in classes should begin with the 'm_' prefix.
      Static fields in classes should begin with the 'g_' prefix.
    </Description>
    <Url></Url>
    <Resolution Name="Static">Prefix the static field '{0}' with 'm_'.</Resolution>
    <Resolution Name="Instance">Prefix the instance field '{0}' with 'g_'.</Resolution>
    <MessageLevel Certainty="95">Warning</MessageLevel>
    <Email></Email>
    <FixCategories>Breaking</FixCategories>
    <Owner></Owner>
  </Rule>
</Rules>


Access Modifiers		Rule Initialization