我们正在尝试根据Microsoft的默认规则为我们公司创建一个自定义规则集，但禁用了一些更具争议性的规则集。这很好用。 StyleCop.Analysers工作得很好，并且适当地创建了警告和错误。它甚至适用于我们的构建服务器。
但是......我在Solution1中添加到ProjectA的规则集列在Solution2中ProjectB的规则集的下拉列表中。这是个问题。如果我选择这个规则集，那么它将在本地工作，但当我在其他任何人检查它时将具有相同的路径。由于我们希望通过nuget提供这些规则集，因此所有公司规则集都具有相同的名称，并且彼此无法区分。因此，即使您的意思是，在您当前的解决方案中找到正确的一个也很难。
这显然很糟糕，我无法相信它是预期的操作模式。我错过了什么？规则集中是否有一个标志使其在本地范围内而不是在整个机器范围内？ Microsoft支持您在项目中创建rulsets，那么为什么它们可以在不相关的解决方案中使用？
我是否需要解决此问题并将其作为VS扩展程序安装一次？对于文本文件来说，这看起来非常复杂。这是VS2017中的错误吗？
任何指针都非常赞赏
- 更新 -
我可以在这里安装rulset：
“C：\ Program Files（x86）\ Microsoft Visual Studio \ 2017 \ Enterprise \ Team Tools \ Static Analysis Tools \ Rule Sets”
他们将被VS2017选中。这很好，但现在如果我尝试在构建服务器上构建它将没有文件，而且人们的机器可能有不同的版本。这是一团糟。
我需要能够将一个规则集添加到解决方案中并在该解决方案中使用它 - 不再进一步。
- 进一步更新 -
看起来这是一个很好的编辑器。如果加载规则集，它会将其添加到它维护的某个内部列表中。每当您转到可用规则集的下拉列表时，它会向您显示仍然可用的规则集。
答案 0 :(得分：2)
所以（除非有人知道更好），看起来这个过程在vs2017中被打破了。我的解决方法是在规则集名称中添加nuget包部署到的项目的命名空间。这并不会阻止下拉列表中的重复，但这意味着您可以实际区分并选择规则集的正确副本。
如何在NuGet安装上转换rulset？添加＆＃34; .pp＆＃34;到文件名的末尾，文件将被解析为占位符。所以在这种情况下我的＆＃34; Test.ruleset.pp＆＃34;文件将有一个节点：
<RuleSet Name="$rootnamespace$ Recommended Debug RuleSet" Description=" " ToolsVersion="15.0">
是的，这就像名字一样冗长，在微软抱怨他们的规则集过程被打破了。
其他占位符可在此处找到： https://msdn.microsoft.com/library/vslangproj.projectproperties_properties.aspx