Referencing a custom code analysis rule library us

问题:

There is not much easy-to-find information regarding custom code analysis rules for Visual Studio 2010. Although this is what I have found in regards to my question...

In the sample library on CodePlex it is shown how to deploy a custom code analysis rule library, which uses a Setup Project to dump the library's DLL into Program Files Folder -> Microsoft Visual Studio 10.0 -> Team Tools -> Static Analysis Tools -> FxCop -> Rules.

Moreover, a very useful how-to blog post by Duke Kamstra also suggests to copy the library's dll into %Program Files%\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\Rules.

My preference is to avoid sticking DLLs in such a global location. I wanted to have the DLL relative to my Visual Studio solutions, so that when I update the DLL with some custom code analysis rule changes then I need not take an extra step to keep dependencies of the DLL up-to-date.

One perfect solution for me would be to have my custom *.ruleset file be aware of the relative path to the DLL, but I've been unsuccessful in doing so.

Any suggestions?

回答1:

In your .ruleset file, you should be able to add relative paths to the custom rule DLLs. e.g.:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Sample" Description="Sample ruleset" ToolsVersion="10.0">
  <RuleHintPaths>
    <Path>..\Tools\FxCop\SomeRules.dll</Path>
    <Path>..\Tools\FxCop\SomeOtherRules.dll</Path>
  </RuleHintPaths>
  ...
</RuleSet>

回答2:

I found even the correct project-relative relative path (provided as Nicole's answer) to my custom rules assembly did not cause my rules to appear in the ruleset editor, while an absolute path to the same assembly did make the rules show up. When I enabled the rules and then changed the path back to a relative path, the rules remain in the editor and are run during source analysis. If I uncheck the rules with a relative path specified, the rules disappear - this seems like a bug in the rules editor.

So, if your rules do not seem to appear when specifying a relative path, try using an absolute one, enabling the rules, and then switching back to a relative path (relative to the project location per @Raithlin).

回答3:

This issue seems to also affect VS 2013. I've found that manually entering the relative path to a rules assembly and the rules from that assembly will result in those rules appearing when I open the ruleset using Visual Studio's ruleset designer UI. The rules will also be ran.

So an operational CustomRules.ruleset could look like this, where SR1000 is a rule from SomeRules.dll and SOR1000 is from SomeOtherRules.dll. Note that the tools version is 12.0 for Visual Studio 2013.

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Sample" Description="Sample ruleset" ToolsVersion="12.0">
  <RuleHintPaths>
    <Path>..\Tools\FxCop\SomeRules.dll</Path>
    <Path>..\Tools\FxCop\SomeOtherRules.dll</Path>
  </RuleHintPaths>
  <Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
    <Rule Id="SR1000" Action="Error" />
    <Rule Id="SOR1000" Action="Warning" />
    <!-- etc. -->
  </Rules>
</RuleSet>

Note that you can easily include standard Microsoft rules by adding includes like this to RuleSet:

<Include Path="minimumrecommendedrules.ruleset" Action="Default" />

回答4:

I am using Visual Studio C# 2015 with Update 2. My custom rules do not show up in the ruleset editor of Visual Studio 2015. However when i run the CodeAnalysis, violations appear if there are any. My RuleHintPath looks like this and is relative to the location of the ruleset file:

<RuleHintPaths>
  <Path>..\Rules</Path>
</RuleHintPaths>

So because the violations are found, it is a fact that the rule DLLs are found by the given relative path. Why the rules do not show up within the ruleset editor is the question. That's why i assume a bug of the editor.