使用TFS检测.NET代码中的重大变化？

Question

每当TFS构建解决方案时，我想检测.NET代码（特别是C＃）的重大变化。如果在签入的代码和最近成功构建的版本之间有任何重大更改（如“A definite guide to API-breaking changes in .NET”中所述），我想了解它。突破性更改不需要导致构建失败。如果没有编写一个使用反射来比较同一个程序集的两个版本的应用程序，那怎么办呢？

Answer 1

详细说明 James 和 Adam 的答案，我想提供一些有关使用NDepend及其检测重大变更的详细信息代码查询和规则功能。 免责声明：我是该工具的开发人员之一

NDepend已经发展并且它的查询语言也是如此。如果您下载NDepend试用版并分析您希望搜索重大更改的代码库的两个版本，请查看以下{{3>默认代码规则组 API重大更改 }}

• CQLinq rules
• API Breaking Changes: Types
• API Breaking Changes: Methods
• API Breaking Changes: Fields
• API Breaking Changes: Interfaces and Abstract Classes
• Broken serializable types
• API: New publicly visible types
• API: New publicly visible methods

执行其中一个代码规则就像例如（NUnit v2.5.8和v2.5.3之间的差异）：

Answer 2

是的，我会（并且确实）使用NDepend。 我致力于为开发人员提供可扩展API的产品。因此，我们需要确保在发行版之间，我们不会删除这些开发人员可能依赖的功能。 另一方面，我们需要灵活地扩展产品，而不会在回归过程中产生大量限制。

您需要考虑的一些事情。

1. 更改引用的DLL的版本应视为重大更改。
2. 删除/更改成员会破坏向后兼容性。
3. 添加成员中断向前兼容性（有些人只是将'添加成员'视为安全，但确实存在相关风险）。
4. 更改每个版本的文件版本，您将需要它。
5. 考虑编写定义“公共API”的合同。这些将是您需要在组织外部支持的成员。将它们视为互操作性边界。然后，它允许您的实现类具有公共成员，这些成员不在API中（因此被认为是“不受支持的”），因此您可以更改它们而无需担心破坏可扩展性API。扩展API包括编写一个新接口（接口名称中带有版本号），该接口不是从先前版本的接口派生的（派生会阻止您完全弃用成员，并且在实现多个接口版本时创建地狱在一个班级。
6. 不要忘记属性，对它们的更改可能不会破坏静态兼容性，但可能会影响运行时。

Answer 3

单元测试。它们提供了一种断言“这就是客户端代码所期望的”的方法。您可以在构建时have TFS run unit tests。

Answer 4

NDepend成名的Patrick Smacchia在大约3。5年前发布了这篇文章。

http://codebetter.com/patricksmacchia/2008/01/20/avoid-api-breaking-changes/

他提到了LibCheck和（显然）NDepend，还有一个评论提到了一个。

由于已经过去3.5年以上，现在可能有更好的选择（LibCheck已经超过6年了），但这些应该是一个开始。