8

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:

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.

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:

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?

edit:

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)

Community
  • 1
  • 1
username
  • 3,378
  • 5
  • 44
  • 75
  • 1
    It's probably my lack of understanding, but I don't get what the tool you're looking for could do better or easier that just compiling the combined sources. I mean, the tool would need both the old and the new source as well to be able to analyze breaking changes the way you intend, wouldn't it? Maybe you can fill me in. – Gert Arnold Nov 26 '11 at 15:26
  • @GertArnold I've updated my question, I would like to automate this process, so it may be not very convenient to compile the source code manually or running a tool manually – username Nov 26 '11 at 15:36

2 Answers2

10

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 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.

Edit1:

I just forgot: The ApiChange tool has actually the functionality you are interested in already. It is the option

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

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.

Alois Kraus
  • 13,229
  • 1
  • 38
  • 64
  • Will this approach work if I will add a new overload that can result in ambiguity in method calls in assemblies that use my API? – username Nov 26 '11 at 15:38
  • A compiler abiguity will not be breaking. I assume you want to find the breaking changes which will require a recompile. It can happen that during a recompile some other method will be used than before but the already built targets should be able to work with the methods they are already linked against. If you want to add such support as well you would need to implement parts of the ECMA C# spec to deal with method overloads and how the C# compiler does resolve them. – Alois Kraus Nov 26 '11 at 15:45
  • Thanks, I have just tested the case I described in my first comment and it works fine – username Nov 26 '11 at 15:59
1

I've spent the day looking around for an answer to this. It seems like the tools referenced on the related (unhelpfully closed) questions are now dead or as good as. But I've just taken a look at Telerik's assembly diff tool JustAssembly and this looks much better than rolling your own, which, if you look at their library seems to be a whole heap of work and likely to go wrong.

They have a UI which isn't of that much help from the point of view of integrating into your CI build, it is pretty basic, but you can build the library from source, which I've just done and the library looks like it has everything you need to get yourself up and running pretty quickly.

satnhak
  • 9,407
  • 5
  • 63
  • 81