我打算在我们正在进行的一个项目中开始使用FxCop。但是，当我尝试选择所有可用的规则时，它看起来像我必须在我的代码中做出很多更改。作为一名“团队成员”，我不能马上开始进行这些更改，比如命名约定更改等等。无论如何，我想开始使用FxCop，并使用最小规则集，并逐渐增加规则集。你能建议我一些必须有FxCop规则，我应该开始关注。或者你有什么更好的方法？对于任何C＃开发人员，哪些是“必须遵循”FxCop规则？
注：我的大部分代码都是用C＃编写的。
设计和安全规则是一个很好的起点。
在我看来，请执行以下操作：
对于任何新项目，请遵循所有FxCop规则。您可能希望禁用其中的一部分，因为并非所有内容对您的项目都有意义。 对于现有的项目，遵循这些类别的规则的最小集合：
因为这些都是典型的与其他类别相比，现有项目中只有少数规则违规，但可能会有所改进您的应用程序的质量。当这些规则是明确的，尝试解决以下几类：
因为这些东西会令你更容易被发现有与违法行为做错误，但现有代码中会有大量违规行为。
总是按级别/修复类别对违规行为进行排序，并从关键行为开始。现在跳过警告。
如果您不知道，还可以从Microsoft获得StyleCop，在源代码级别检查您的代码。确保在安装过程中启用MSBuild集成。
我们是一家网上商店，所以我们把下列规则：
偶尔我们将下降约在依赖关系使用更高的框架规则我们的一些CMS的的仍然是.NET 2.0，但是这并不意味着DAL /业务层可以只要你不试图返回一个IQueryable（或者.NET 3，3.5）。
我完全同意Sklivvz。但对于现有项目，您可以按类别清理FxCop违例类别。
Gendarme不时接受一些非常有用的新规则。所以你可以使用Gendarme。
在我们的过程中，我们启用了所有规则，然后我们必须证明任何压抑是我们审核过程的一部分。通常，以时间有效的方式修复错误是不可能的，因为截止日期或错误会引发错误（这有时会发生 - 特别是如果您的体系结构通过反射来处理插件）。
我们还为全球化编写了一个自定义规则来替换现有规则，因为我们不想全局化传递给异常的字符串。
总的来说，我认为最好尝试并遵守所有规则。在我目前的家庭项目中，我有四种构建配置 - 一种指定CODE_ANALYSIS定义，另一种则不指定。这样，我可以通过构建非CODE_ANALYSIS配置来查看所有我已经禁止的消息。这意味着可以定期查看被抑制的消息，并根据需要进行处理或删除。
长远来看，我想要做的是构建一个步骤，根据实际错误分析SuppressMessage属性并突出显示那些不再需要的抑制，但目前对于我的设置不可行。
FxCop的替代方法是使用NDepend工具，它可以编写Code Rules over C# LINQ Queries (namely CQLinq)。 声明：我是该工具的开发人员之一
默认情况下建议使用超过200 code rules。定制现有规则或创建您自己的规则非常简单，这要归功于着名的 C＃LINQ语法。
NDepend与FxCop在某些代码规则上重叠，但提出了大量的唯一代码规则。这里是我会为归类一些规则必须遵循：
请注意，可以验证规则live in Visual Studio并在构建过程时间，generated HTML+javascript report。
一次打开一条规则。修复或排除它报告的任何警告，然后从下一个警告开始。
一些规则避免我们的错误或泄漏：
有些帮助我们有一个更好的设计，但要小心，当中央API受到影响时，它们可能会导致大的重构。我们喜欢
有人在我们的项目上尝试了性能规则没有任何改进。 （实际上，这些规则是关于微观优化的，如果没有瓶颈识别显示需要进行微观优化，则不会给出结果）。我会建议而不是从这些开始。
最小的FxCop也代码分析（如果使用VS2010高级版或旗舰）如下：http://msdn.microsoft.com/en-us/library/dd264893.aspx
+1了StyleCop，它的ReSharper很好地集成了。在你的代码中强制执行编码标准，如果它足够好并且正常工作，你最终可能会让其他人加入进来，但是要做好长期准备！ – 2010-01-27 11:01:38