.NET: with respect to AssemblyVersion, what defines binary compatibility?

Question

What changes to a strong-named assembly necessitate a change in AssemblyVersionAttribute? Clearly, changing the public api in a way that could require a client to have to make a

Answer 1

Microsoft adds new methods/classes in .NET libraries in service pack releases without changing AssemblyVersion (still 2.0.0.0 / 3.0.0.0). Microsoft only changes the AssemblyFileVersion. For example, In .NET 2.0 SP1, DateTimeOffset struct was added.

Should this practice be recommended to us because Microsoft do this? It is confusing.

Answer 2

adding methods to an interface shouldn't be fine because old providers won't implement the new methods.

Answer 3

In response to Martijn's bounty:

The best reference on binary compatibility is on the community Wiki.

A definite guide to API-breaking changes in .NET

Answer 4

It's pretty easy... as long as Types remain unchanged (in their public or protected layout) and method signatures are not changed (adding methods or types is fine), the JIT should be able to link the DLL just fine.

That said, I think that even if it does work you should not do this. Make a new version and use a policy to map the old version to the new one, if required. Otherwise you drive yourself straight back to DLL hell... and I'm pretty sure you don't want that.