Check and Visit

During analysis, FxCop recursively traverses through the nodes that make up your assemblies. The most interesting nodes are ModuleNode objects, TypeNode objects (such as ClassNode), and Member objects (such as PropertyNode and Method).

When FxCop encounters such a node and the TargetVisibility is consistent with any visibility filtering that your rule has specified, it calls a Check method. You can override any (or all) of the following methods inherited from BaseIntrospectionRule. By default, these methods perform no operation unless you override them to implement your rule:

Check(ModuleNode module) — Checks a .NET module (an assembly consists of one or more modules).
Check(Resource resource) — Checks a resource (such as a Bitmap) defined in a module.
Check(String namespaceName, TypeNodeCollection types) — Checks types in a namespace.
Check(TypeNode type) — Checks a type (such as ClassNode, Struct, EnumNode, or others).
Check(Member member) — Checks a member (such as a PropertyNode, Method, Field, or others).
Check(Parameter parameter) — Checks a parameter for a member.

Note

	Note
In general, use the most specific override possible when implementing your rule. For example, if checking that classes follow a naming convention, override `Check`(`TypeNode` type). If you override a method that is too general and drill down through the nodes yourself, FxCop may have trouble identifying which node you are actually checking. This will affect how the results are displayed to the user.

In general, use the most specific override possible when implementing your rule. For example, if checking that classes follow a naming convention, override Check(TypeNode type). If you override a method that is too general and drill down through the nodes yourself, FxCop may have trouble identifying which node you are actually checking. This will affect how the results are displayed to the user.

When you override one of these methods, you should always return this.Problems in C# or Me.Problems in VB.NET. It is okay to return this way even if no problems were detected by your rule.

In some cases, you may want to check nodes that are deeper than the Member level such individual Statement nodes. In this case, you can call a method that starts with "Visit" to initiate a drilldown. All child nodes will then be recursively visited. You can override Visit methods logically deeper in the node tree to execute code once nodes of those types are visited by the recursion. In such an override, you must call the base class implementation if you want recursion to continue deeper. For example, the following processes all AssignmentStatement nodes in a Method:

public override ProblemCollection Check(Member member)
{
  Method methd = member as Method;
  if (methd != null)
  {
    VisitStatements(methd.Body.Statements);
  }
  return this.Problems;
}

public override void VisitAssignmentStatement(AssignmentStatement assignment)
{
  // Process assignment statement. Add to this.Problems if problems are found.

  // Uncomment the following if you need to recurse deeper (for example, to the Expression level).
  // base.VisitAssignmentStatement(assignment);
}


Rule Initialization		Problems and Resolutions