我有一个提供API的程序集，并被其他程序集使用。我需要验证较新版本的API dll是否仍然与使用旧版API的旧程序集兼容。
我发现了一些问题相同的问题，但没有解决问题的答案：
建议的工具只能比较两个程序集，并说明API中是否存在重大更改，但如果最新的API确实破坏了使用它的旧程序集，则不会。 我想找一个工具或编写一个测试，以便检查每个旧的dll是否可以使用我的新API dll。
至于API的变化，我更有可能只扩展它，但即使它仍然可以破坏旧程序集中的代码。这些变化的一些例子可以在这里找到：
目前我看到的唯一解决方案是使用最新的API编译旧程序集的源代码，但我想只使用程序集并将它们作为单元测试的一部分添加。有没有更好的方法可以解决这个问题？
编辑：
我正在寻找能够自动验证.net程序集之间向后兼容性的过程的工具。 （命令行或者也有一些api）
答案 0 :(得分：10)
你想要的是做一个差异并生成一个重大变化列表。然后，您想要搜索您的程序集是否使用任何损坏的API。您可以使用ApiChange工具执行此操作以执行差异并查找其受影响的任何用户。
使其更具体。如果已从接口中删除方法，则需要在使用接口方法的类或任何实现此方法的类中查找此方法的所有实现者和用户。
ApiChange可以使用命令-whoimplementsinterface和-whousesmethod在命令行上搜索特定方法的实现者和用户。它不是在命令行自动执行，但您可以直接使用ApiChange.Api.dll自动执行此查询。
编辑1：
我忘记了：ApiChange工具实际上已经是您感兴趣的functionality。这是选项
-ShowrebuildTargets -new -old [-old2] -searchin
我们确实在我们的部门使用它并取得了良好的效果。唯一的问题是XML Intellisense文件。如果另一个目标不使用已删除的方法但在XmlDoc中引用它，编译器将写入一个警告，表明引用了一个非现有方法。这很难捕获并且还涉及解析intellisense docu文件。但这是一个非常有利的案例。
答案 1 :(得分：0)
我花了一整天的时间来寻找答案。似乎相关（无益关闭）问题上引用的工具现在已经死了或者好了。但我刚刚看了一下Telerik的汇编差异工具JustAssembly，这看起来比滚动你自己要好得多，如果你看看他们的库似乎是一大堆工作而且可能出错。
他们有一个UI，从集成到CI构建的角度来看，它没有那么大的帮助，它是非常基本的，但你可以从源代码构建库，我刚刚完成了库和库看起来它拥有让你自己快速上手和运行所需的一切。