This happens because the rule name (as opposed to its class type name) is not contained in the violation message in the FxCop report generated by the Code Analysis run. In theory, Visual Studio could (and probably should) look for the rule name under the <Rules>
node in the report before it starts looking elsewhere. However, it doesn't in VS 2012. Instead, it only gets the rule names from rule information acquired from loaded rule assemblies.
The tricky thing here is that, for UI display purposes, Visual Studio is doing a completely separate search and load of rule assemblies than is done in the Code Analysis runs. The latter is performed by running fxcopcmd.exe
with a command line generated off MSBuild properties. The former uses completely separate logic embedded in the Visual Studio plugins for Code Analysis, and it doesn't take the project-level rule locations or ruleset files into account. (It seems to be done via the Microsoft.VisualStudio.CodeAnalysis.ManagedRuleProvider
class in the CodeAnalysis.dll
assembly, if you're curious about the gory details.)
So... You basically have two choices if you want to see the rule names:
Put your rule assembly in the
<VS install directory>\Team Tools\Static Analysis Tools\FxCop\Rules
folder so that it gets picked up by Visual Studio.Add an
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\Code Analysis\FxCopRulePath
registry node (create a new key namedCode Analysis
, with a space, instead of using the existingCodeAnalysis
) with a value like the following to allow both your rules and the built-in rules to have their names displayed:%FxCopDir%\Rules;C:\Foo\Bar\YourRulesFolder