下面是示例代码。
<?xml version="1.0" encoding="utf-8"?> <RuleSet Description="Analyzer rules for Demo." ToolsVersion="15.0"> <Rules AnalyzerId="StyleCop.Analyzers" RuleNamespace="StyleCop.Analyzers"> <!-- Using statements must be inside a namespace --> <Rule Action="None" /> <!-- The file header is missing or not located at the top of the file --> <Rule Action="None" /> </Rules> </RuleSet>同时，还要修改csproj文件
<PropertyGroup> <!-- other... --> <TreatWarningsAsErrors>true</TreatWarningsAsErrors> <!-- 加下面2行,处理SA0001 --> <GenerateDocumentationFile>true</GenerateDocumentationFile> <NoWarn>$(NoWarn),1573,1591,1712</NoWarn> <!-- 加下面这行,自定义代码分析规则集 --> <CodeAnalysisRuleSet>..\test.ruleset</CodeAnalysisRuleSet> </PropertyGroup>去掉代码的头部，和把using放到外面，再build一下项目，就可以正常通过了。
既然可以自己定义，那么就必然有这样一个问题，每个人可能都会想把自己的习惯放开，这样的话，这个规则就是一个透明的存在了！！
换句话说，必须要有一些硬性规定，必须要有一些取舍。我们可以向某些开源项目借鉴，同时在他的基础上做简单的添加删除，个人觉得应该可以适应大多数的情况了。
下面放出几个觉得不错的参考。
Autofac 目前我就是以这个为基础的
EntityFrameworkCore
在代码分析规则集的基础上，还可以用Stylecop.json来微调某些规则的行为。
当把SA1633恢复之后，提示的第二个选项就是添加Stylecop.json配置文件
添加之后，还要在csproj里面做设置
<ItemGroup> <AdditionalFiles Include="stylecop.json" /> </ItemGroup>关于Stylecop.json的具体配置，可以参考Configuring StyleCop Analyzers，这里不继续展开。
除了上面的办法，还可以通过安装扩展StyleCop来处理。
安装后，右击项目的时候就可以看到StyleCop相关的菜单。
在团队内保持一样的编码风格，并能在开发过程中纠正相应的错误，这是编写可维护和可读代码的重要一步，同样也是代码审查的重要一步！
当然，在团队内推行这类规范，还是要多多听取团队成员的意见，也要定时检查规则是否需要更新，毕竟时代在进步！只要达成一致，就是好规则，就应该要遵守。
StyleCop是一个很不错的工具，用的好就是利器。可以把它和cli模板项目相结合，这样创建的新项目就都“内嵌”了一样的规则了。
友情提示，在老项目添加这个要慎重，不然会有一阵阵酸爽。