如何测试 .net 程序集之间 API 的向后兼容性 [英] How can I test the backward compatibility of API between .net assemblies
问题描述
我有一个程序集，它提供了一个 API 并被其他一些程序集使用.我需要验证新版本的 API dll 是否仍然与使用旧版本 API 的旧程序集兼容.
I have an assembly that provides an API and is used by some other assemblies. I need to verify that a newer version of API dll is still compatible with the older assemblies that were using the older version of API.
我发现了几个提出相同问题的问题，但没有解决我的问题的答案:
I've found a couple of questions that ask the same, but there are no answers that resolve my problem:
建议的工具只能比较两个程序集，并说明 API 中是否存在重大更改，但不能说明最新的 API 是否真的破坏了使用它的旧程序集.我想找到一个工具或编写一个测试来检查每个旧的 dll 是否可以与我的新 API dll 一起使用.
Suggested tools can only compare two assemblies and say if there are possible breaking changes in API, but not if the newest API really breaks the older assembly that uses it. I'd like to find a tool or write a test that will be able to check whether each of the older dlls can work with my new API dll.
至于 API 的变化更有可能我只会扩展它，但即使它仍然可以破坏旧程序集中的代码.可以在此处找到此类更改的一些示例:
As for the changes in API more likely that I will only extend it, but even though it still can break the code in older assemblies. Some of the examples of such changes can be found here:
目前我看到的唯一解决方案是使用最新的 API 编译旧程序集的源代码，但我只想使用程序集来执行此操作并将它们添加为我的单元测试的一部分.有什么更好的方法可以处理吗?
For now the only solution I see is to compile the source code of the older assemblies with the newest API, but I would like to do it only with assemblies and add them as part of my unit tests. Is there any better way I can handle that?
我正在寻找一种工具，该工具能够自动化验证 .net 程序集之间的向后兼容性的过程.(命令行或一些api)
I'm looking for a tool that will be able to automate the process of verifying the backward compatibility between .net assemblies. (command line or with some api too)
推荐答案
您想要做一个差异并生成一个重大更改列表.然后您想搜索您的程序集是否确实使用了任何损坏的 API.您可以使用 ApiChange 工具执行此操作以执行差异并查找任何受影响的用户.
What you want is to do a diff and generate a the list of breaking changes. Then you want to search if of your assemblies does use any of the broken APIs. You can do this with ApiChange tool to do the diff and to find any affected users of it.
为了使它更具体.如果您从接口中删除了一个方法，那么您需要在使用接口方法的类或任何实现此方法的类中找到此方法的所有实现者和用户.
To make it more concrete. If you have removed a method from an interface then you need to find all implementers and users of this method in classes which uses the interface method or any class that does implement this method.
ApiChange 可以使用命令 -whoimplementsinterface 和 -whousesmethod 在命令行上搜索特定方法的实现者和用户.它不是在命令行中自动执行的，但您可以直接使用 ApiChange.Api.dll 来自动执行此查询.
ApiChange can search for implementers and users of specific methods on the command line with the commands -whoimplementsinterface and -whousesmethod. It is not automated at the command line but you can directly use the ApiChange.Api.dll to automate this queries.
编辑 1:
我忘了:ApiChange 工具实际上具有 功能已经有兴趣了.这是选项
I just forgot: The ApiChange tool has actually the functionality you are interested in already. It is the option
-ShowrebuildTargets -new -old [-old2] -searchin
-ShowrebuildTargets -new -old [-old2 ] -searchin
我们确实在我们的部门使用了它并取得了良好的效果.唯一的问题是 XML Intellisense 文件.如果另一个目标不使用已删除的方法，而是在 XmlDoc 中引用它，编译器将写入一个警告，指出引用了不存在的方法.这很难捕捉，并且还涉及解析智能感知文档文件.但这是一个非常边缘的情况.
We did use it in our department with good results. The only gotcha are the XML Intellisense files. If another target does not use the removed method but references it inside the XmlDoc the compiler will write a warning that a non existing method was referenced. This is quite hard to catch and would involve to parse the intellisense docu files as well. But this is quite an edge case.
这篇关于如何测试 .net 程序集之间 API 的向后兼容性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
