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

Question

每当TFS构建解决方案时,我想检测.NET代码(特别是C#)的重大变化.如果在签入的代码和最近成功构建的版本之间存在任何重大更改(例如" .NET中的API破坏更改的明确指南 "中所述),我想了解它.突破性更改不需要导致构建失败.编写一个使用反射来比较同一个程序集的两个版本的应用程序,如何做到这一点？

Answer 1

为了详细阐述James和Adam的答案,我想提供有关使用NDepend及其代码查询和规则功能检测中断更改的详细信息.免责声明:我是该工具的开发人员之一

NDepend已经发展了它的查询语言.如果您下载NDepend试用版并分析您希望搜索重大更改的代码库的两个版本,请查看以下CQLinq规则的默认代码规则组API Breaking Changes.

• API突破变化:类型
• API突破变化:方法
• API重大变化:字段
• API重大变化:接口和抽象类
• 断序的可序列化类型
• API:新的公开可见类型
• API:新的公开可见方法
• API:新的公开可见字段

执行这些代码规则之一就像例如(NUnit v2.5.8和v2.5.3之间的差异):

Answer 2

是的，我会（并且确实）为此使用NDepend。我致力于为开发人员提供可扩展API的产品。因此，我们需要确保在发行版之间不删除那些开发人员可能依赖的功能。不利的一面是，我们需要灵活的产品开发能力，而又不会在版本转换方面带来巨大的限制。

您将要考虑的一些事情。

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