.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 code change requires an increase in AssemblyVersion. But what about changes to the public API that don't require code changes in the client? For instance:

• the addition of a public class or interface?
• the addition of a public member to a public class or interface? (EDIT: drscroogemcduck correctly points out below that adding a member to an interface would hose all implementors. Silly me.)
• an increase of visibility of a class member?

There's got to be definitive documentation of this somewhere on MSDN (or, knowing MS, on some MSSE's personal blog). But I simply cannot find it. Please help!

Answer 1

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 2

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.

Answer 3

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