How can I check backward API compatibility between .net assemblies

Question

I have an assembly that provides an API and is used by some other assemblies. I need to verify that the new version of the DLL API is still compatible with older assemblies that used an older version of the API.

I found a couple of questions that ask the same thing, but there are no answers that solve my problem:

• Public API Compatibility Checker
• Backward compatibility tool for the C # /. NET API.

The tools offered can compare only two assemblies and say if there are any possible changes in the API, but not if the latest API really destroys the old assembly that uses it. I would like to find a tool or write a test that can check if each of the old DLLs can work with my new DLL-API.

As for the changes to the API, it is more likely that I will expand it, but even though it can still break the code in older builds. Some examples of such changes can be found here:

• Specific Guide to API Changes in .NET
• .NET: regarding AssemblyVersion, what determines binary compatibility?

So far the only solution that I see is to compile the source code of old assemblies with the latest API, but I would like to do this only with the help of assemblies and add them as part of my unit tests. Is there a better way I can handle this?

edit:

I am looking for a tool that can automate the process of checking backward compatibility between .net assemblies. (command line or with some api too)

Answer 1

What you want is to make diff and create a list of violations. Then you want to search if your assemblies use any of the broken APIs. You can do this with the ApiChange tool to run the diff and find all the users affected by it.

To make it more specific. If you removed a method from an interface, you need to find all the developers and users of this method in classes that use the interface method or any class that implements this method.

ApiChange can search for executors and users of specific methods on the command line with the -whoimplementsinterface and -whousesmethod commands. It is not automated on the command line, but you can directly use ApiChange.Api.dll to automate these requests.

Edit1:

I just forgot: the ApiChange tool actually has functionality in which you are already interested. This is an option.

-ShowrebuildTargets -new -old [-old2] -searchin

We used it in our department with good results. The only access is the Intellisense XML files. If the other target does not use the remote method, but refers to it inside the XmlDoc, the compiler will write a warning that it referred to a nonexistent method. This is pretty hard to catch and will include analysis of intellisense document files. But this is a rather brief case.