8

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!

cero
  • 691
  • 3
  • 9

4 Answers4

5

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

Community
  • 1
  • 1
ErnieL
  • 5,685
  • 20
  • 27
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.

Lucero
  • 56,592
  • 6
  • 112
  • 151
  • Two questions: * can you point me to documentation--official or otherwise--on your first statement? * would you mind elaborating on your second statement? In this paticular case, I want to increase the visibility, from internal to public, of the ctor of a public class. It's unclear to me how this could lead to (the GAC version of) DLL hell. – cero Apr 20 '09 at 15:53
  • First: I'd have to look for it. Basically, the JIT does compile methods as late as needed. The final binding occurs only when the JIT compiles the method, so if the method is there and matches the signature, it will work - that's my experience. Adding methods to public interfaces would not be a good idea though, since that could lead to missing methods. – Lucero Apr 20 '09 at 16:43
  • As for the second statement, changing code and leaving its assembly identity the same can lead to different behavior. For instance, when you do reflection, you specify whether you want to find private or public members. If one only used "private" binding, it will not longer find the ctor (in your case), and the user would get an error message even though he (and the runtime) thinks its the same version... and it may confuse the runtime if the assembly was in the GAC also. Don't do it. – Lucero Apr 20 '09 at 16:46
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.

linquize
  • 18,414
  • 9
  • 55
  • 78
1

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

benmmurphy
  • 2,461
  • 1
  • 19
  • 28