Using reflection to List version to version assembly changes: Libcheck, one of the best tools ever! [Kit George]

OK, so libcheck has been around for a while. I actually made the code available publicly in the past via GotDotNet, but when I released it there, it was called WinChurn. Libcheck remains the core of this functionality, and it’s an awesome little tool.

Basically, libcheck analyses a version of a library, and compares it to another version of the same library. It then reports the differences (it only looks at the public interface by thway, expect for one or 2 exceptions to that rule of thumb) in a list, available as html or xml. Because we don’t like interpreting too far, the list is presented as a set of removed, and added methods. When we can detect that change in question is a breaking change (and generally, removals are likely candidates!), we color the change red.

Now if you’re used to the change report we put out periodically with a release, you now have the tool that generates that list! And even cooler, you can run the tool on your own code, to inform your own customers/consumers what has changed between one version of your assembly, and the next.

If you’re interested in the history of libcheck, it was initially developed by Brad Abrams, and then I took it over and owned it for a good while. THe most recent incarnation is owned by Robert Villahermosa, who’s done a great job at including an excellent document which describes how to use the tool as part of the submission: thanks to Rob. Rob runs the tool weekly on our own assemblies in order to help identify breaking changes, which we then file bugs on and roll back the change (if/when detected), so we actually use it in the development of the framework.

LibCheck is available on the BCL Website (see the Library Analysis section), or you can simply download it directly from the MSDN Downloads page. And any feedback is is greatfully appreciated! (

Comments (6)

  1. Anonymous says:

    Thank you!

    I’ve been working on my own version for a long time now and I’ll dig into your implementation details to find out how you handle the mscorlib.dll case. This is almost the only assembly that you can’t load using Reflection if you are not built against the same version of the CLR you are trying to load.

  2. Anonymous says:

    I’m not convinced we solve this case directly Christophe. If you look at how the tool is implemented, we actually simply create ‘store’ files, which means you don’t have to run against an old assembly, you can just use some store files from the old assembly.

  3. Anonymous says:

    The following links to .NET resources have been collated over time with the assistance of colleagues. …