Each rule has a ProblemCollection inherited from BaseIntrospectionRule. The rule is expected to add objects of type Problem to this collection as violations of the rule are detected during the traversal described in the preceding section.

When you construct a Problem, you select the Resolution string in your XML resource to be displayed to the user to assist the user with investigating and correcting the problem. If your rule only has once Resolution defined in its XML, use the rule's inherited GetResolution method to retrieve it. Otherwise, use GetNamedResolution, passing the value of the Name attribute in your XML that distinguishes the particular resolution. The methods for obtaining the resolution from the XML also take an optional paramarray of values to fill positional placeholders (such as {0}, {1}, etc.) in the resolution. The syntax is the same one used by String.Format.

Now for something a little tricky. Some overloads of the Problem constructor have a String id parameter. Usually you do not need to use these overloads but can instead stick to the simple one that just takes a Resolution object. The case where you need to use id is when a single Check method has the potential to add more than one Problem to the ProblemCollection. For example, consider the case where you might examine all of a method's local variables during Check(Member member) and potentially add anywhere from zero Problem objects up to the total number of local variables in the method. The id parameter lets you uniquely identify each of the Problem objects you add within the scope of the same Check method. In this local variable example, you might choose to use the name of the local variable as the id.