Sometimes you find yourself wanting to compare two versions of a .NET assembly as a way getting your head around all the changes that might be happening a your project. Perhaps you're writing a Framework for consumption by other developers.
There's a few different kinds of change you want to concern yourself with.
First is the "public face" of your assembly - the interface or 'linking' contract it makes with other assemblies that might choose to reference it.
Second is the semantic contract that is made. Most folks expect certain things of your assembly. They give you two "1's" and they expect a "2" in return. Sometimes people start to rely on bugs and you have to make breaking changes.
Breaking changes like deletion or modification of existing assemblies can, of course, wreak havoc.
One word to describe the changes that happen between versions - and many versions over time - is "churn." What percentage of the "surface area" of your assembly has changed? If a large number of things change it implies that the assembly is still being actively designed, or that the problem area isn't well understood. If very few things change and/or what does change is only additive, it implies that the assembly is fairly stable and can be counted on.
Here's some tools I use to get an understanding of what's changed between binary versions of an assembly, without resorting to source-level diffs.
Being acutely aware of what's changed and avoiding the surprise of a breaking change can greatly reduce the stress level of your whole team as you deliver. I use all three of these tools and I encourage you to check them out.
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.