我是TFS配置的新手。
目前我们的项目完成了50％，但我们发现我们的代码非常糟糕。我们认为需要像Resharper这样的静态代码分析，或者像StyleCop，CodeAnalysis和FxCop这样的其他产品。
我们希望配置TFS在签入时包含触发代码分析警告的代码时拒绝签入。
但对于之前的代码，我们希望抑制现有警告，以防止代码变得比现在更糟。
答案 0 :(得分：3)
正如Ivan所提到的，你的根本原因不在于缺乏分析工具，而在于开发团队和项目赞助商之间达成的（或目前正在团队成员之间）达成的质量和严格程度。可能是团队的压力太大，导致重要的审查行动被忽略，或者团队（或赞助商！）与您或赞助商没有同样的质量愿望。或者说团队没有足够的知识来防止这些问题的发生。
最好的方法是在短时间内尽可能多地修复。
警告：我与许多团队一起经历了同时启用太多规则的效果。一般来说，人们不愿意承认他们的工作没有达到标准，并且制定不直接导致错误的规则（例如，“标识符不正确”）可能会导致挫败感，从而严重阻碍您的动力。仔细选择现在需要解决的规则以及可以等待以后的规则在我的经验中工作得更好。一旦团队开发出解决这类问题的方法，您就可以轻松应用更多。
启用configuring Code Analysis for your solution之类的工具或使用Resharper的解决方案范围分析功能，可以帮助您发现问题，但除非您的团队停止创建，否则它将无法解决问题或阻止类似问题在未来出现他们。
提示：请注意，您也可以在构建期间启用Resharper using the Resharper CLI features。
StyleCop如果代码本身足以触发可能存在错误和问题的大量警告，我就不会强制执行此团队。首先修复这些问题，稍后再编译代码。您现在的优先事项是删除任何可能的错误。
CodeAnalysis和FxCop是相同的东西，所以你不需要打开它们。像Resharper这样的工具可以帮助开发人员使用魔术键 ALT + ENTER 快速删除许多问题。
如果要创建干净的基线，可以运行一次代码分析，然后选择生成的所有警告，然后选择全局抑制文件中的抑制。这将适用于代码分析问题，但不会抑制任何编译器警告，没有简单的方法可以快速抑制所有当前的编译器警告。
提示：有时可以暂时重命名任何现有的
globalsupressions.cs文件，以便分别存储此“基线”。然后，您将知道在以后的某个时间点需要修复的警告。提示：当开发人员抑制警告时，让他们为生成的抑制添加
Justification="Reason for suppression"，这样就可以区分仔细考虑的抑制和临时抑制。
根据您是否已有构建服务器，下一步是install Team Build，一旦拥有构建服务器，您需要setup a Build Definition。这blog post covers most of the steps。
在构建定义中，将触发器设置为“Gated Checkin”，并在Process选项卡上确保将Code Analysis设置为“Always”。 If you want to fail your build based on Code Analysis errors, you need to create a custom ruleset and configure that for your solution
如果编译器错误导致构建失败，您还可以启用“将警告视为错误
”启用门控签入构建后，系统将提示所有开发人员更改等待构建完成。 You can turn on alerts (using Web access) or use the Build Notification Tool to get notified when the changes were successfully submitted。
提示：您可以选择一次打开几个规则并修复它们，而不是一次打开所有规则（或将它们全部切换为在构建期间导致错误）。按类别开启规则为您提供了一个很好的机会，可以教会人们开启规则的重要性以及解决这些规则的可能解决方案。
更高级的解决方案是在Team Build环境中安装和配置SonarQube。 The ALM Rangers and Sonar have recently worked together to create installation guidance and a number of extensions to enable Team Build and SonarQube integration。你可以find the installation guide here。