使用TFS检测.NET代码中的重大更改？

每当TFS构建解决方案时，我都希望检测到.NET代码（特别是C＃）的重大更改。如果在检入的代码和最近成功构建的版本之间有任何重大更改（如“A definite guide to API-breaking changes in .NET”中所述），我想知道它。重大更改不一定会导致构建失败。编写一个使用反射来比较同一程序集的两个版本的应用程序，这怎么能做到呢？使用TFS检测.NET代码中的重大更改？

来源

2011-08-30 jalbert

通过代码审查？ – Mrchief

链接的问题：http://stackoverflow.com/questions/2377855/tool-for-backwards-compatibility-for-the-c-net-api – aponomarenko

是的，我会（并且）为此使用NDepend。我致力于为开发人员提供可扩展API的产品。因此，我们需要确保在发布之间，我们不会删除那些开发人员可能依赖的功能。另一方面，我们需要灵活性来扩大产品的范围，而不会对版本造成大的限制。

有些事情你会想要考虑。

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

来源

2011-09-12 05:19:28 Adam

详细说明＃1？如果我的Apple.dll依赖于Bear.dll的v1版，并且我升级到了Bear.dll的v1.2版本，并验证Bear.dll不会按照其他＃2-6公开任何重大更改？ Apple.dll用户不应该因为正确的结果而遭受任何破坏？只要我确保所有引用的dll都符合相同的标准，无论何时我更新引用的DLL，那么应该没有问题是正确的？ – AaronLS

嗨AaronLS。这是一个很好的问题，我原本应该详细阐述＃1。如果Apple.dll的公共功能返回在Bear.dll中声明的类型，则会出现风险。如果这些程序集是强类型的，那么依赖于Apple的产品将期望该函数调用返回（完全限定类型名称）“Type，Bear，v1.1”。如果你的Apple.dll有“hot fixed”（已更改但未被反编译），它现在将返回“Type，Bear，v1.2”，并且运行时会抛出类抛出异常 - 因为强命名类型被所有名称组件，包括版本。 – Adam