Game Development Reference
In-Depth Information
public NamespacePrefix() : base(“NamespacePrefix”)
{
}
public override ProblemCollection Check(string namespaceName,
TypeNodeList types)
{
if (!namespaceName.StartsWith(“Nexus.WorldBuilder”))
{
string[] arguments = new string[1] { namespaceName };
Resolution resolution = GetNamedResolution(“Default”, arguments);
Problems.Add(new Problem(resolution));
}
return Problems;
}
}
}
You should notice that there is a collection called Problems with no apparent dec-
laration. This property is declared in the BaseIntrospectionRule class, and is the
collection you must add Problem objects to and return from the Check method. Do
not create a new ProblemCollection as it will not work. Be sure to return null if no
errors occurred. Lastly, you need to modify AssemblyInfo.cs in a couple of places
and also give the assembly a strong name key.
Add the following lines near the other assembly attributes:
[assembly:CLSCompliant(true)]
[assembly:ComVisible(false)]
If everything compiles correctly, you are halfway there! The real parlor trick is getting
FxCop to recognize the rules in your assembly. The custom rules importer is very
strict, and quite often it forces you to pull your hair out just to get custom rules to
import. Thankfully, the latest version of FxCop outputs XML configuration errors,
whereas the older versions did not and required some clever debugging to fix. You
can import custom rule assemblies by selecting Add Rules from the Project menu.
If FxCop fails to load your rules, be sure to read the messages left in the output
window of FxCop. If the custom rules loaded correctly, you can try them out. You
should have output similar to Figure 13.8 after analyzing an assembly that violates
the namespace prefix rule defined in this example.
Search Nedrilad ::




Custom Search