Geek Answers Handbook

.NET: As for AssemblyVersion, what determines binary compatibility?

What changes in a strong named assembly require a change in AssemblyVersionAttribute? Obviously, changing the public api in a way that might require the client to change the code requires an increase in AssemblyVersion. But what about changes to a public API that doesn't require code changes in the client? For example:

  • adding an open class or interface?
  • adding an open member to an open class or interface? (EDIT: drscroogemcduck correctly points out below that adding a member to an interface will spank all developers. Stupid me.)
  • increasing class member visibility?

There should be final documentation about this somewhere on MSDN (or, knowing MS, in some kind of personal MSSE blog). But I just can't find him. Please, help!

+7
c # clr gac
source share
4 answers

This is pretty easy ... as long as the types remain unchanged (in their public or protected layout) and the method labels are not changed (adding methods or types in order), the JIT should be able to bind the DLL just fine.

However, I think that even if it works, you should not do it. Create a new version and use the policy to map the old version to the new one, if necessary. Otherwise, you will simply return to the DLL addon ... and I'm sure you do not want this.

+4
source share

In response to the Martijn Award:

The best binary compatibility link on the Wiki community.

Specific Guide to API Changes in .NET

+5
source share

Adding methods to the interface does not have to be accurate, because old providers will not use new methods.

+1
source share

Microsoft adds new methods / classes to .NET libraries in service pack releases without changing AssemblyVersion (still 2.0.0.0/3.0.0.0). Microsoft is only changing AssemblyFileVersion. For example, a DateTimeOffset structure was added in .NET 2.0 SP1.

Should we recommend this practice because Microsoft does it? This is confusing.

+1
source share

More articles:


All Articles