When to Change File/Assembly Versions?

Suzanne Cook has been blogging about assembly loading over on gotdotnet recently, and it's been interesting stuff.  There was one piece that kinda threw me, though:

Non-Shipping Builds

"In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. However, I recommend against that for non-shipping builds: it doesn’t avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine."

-Suzanne Cook


On the contrary, version numbers should always change! How many of you remember programming in the 16-bit world before file versions were commonplace?  Me neither, actually, but I have the dubious pleasure of working on a legacy application with this very problem. I have no desire to propogate those same issues into my beloved .NET world, where the streets are paved with gold, and the...  Oh, wait.  Let's get back to the point.

There's a reason for version numbers - use them!!! They are an almost unlimited resource.  Increment often!

By deploying assemblies (even in-house) without incrementing version numbers, you invite true DLL hell.  Which version of 1.2.3.4 has the implementation of foo() changed in?  Not sure, are we?  Can you even tell the difference between this 1.2.3.4 and that 1.2.3.4 without ILDASM?

I cannot stress this strongly enough - every time a dll leaves a developement machine (or more preferably, a build machine), the version number should be incremented.  Period.  End of story.

Several of the problems Suzanne mentions are architectual issues with the framework - for example, shes point out that xcopy deployment does not address publisher policy, and for that reason, publisher policy should be avoided for non-release builds.


Actually, this merely points to the fact that xcopy deployment is fundamentally weak.  It is only usefull in the simplest deployment models, and even then has problems.  I'm certain many people here have run into IIS caching issues, haven't we?  XCopy not working?  Write an installer.  Working with a webhost? You're probably out of luck.  If it bugs you enough, go bother Microsoft.  They are actually pretty responsive these days.  Come up with a feature request and I bet they'll listen.

Suzanne really does know what she is talking about when it comes to assembly loading issues, and I've read most of her blog with great interest - But I just couldn't let this one pass by.

4 Comments

  • In the first paragraph Suzanne says: "First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don’t change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that."





    I'm curious; why do you prefer using the assembly version over the file version as Suzanne recommends? Her suggestion seems to give you the best of both worlds.


  • By not changing the assembly version, we are telling the loading assembly that there are no breaking changes in this version of the assembly. This assumes that developers are skillful enough to know when they have made breaking changes. Past experience has shown that this is not usually the case. Subtle and difficult to track "DLL hell" problems are often created this way. How many times have you run into a COM developer that made a breaking change to the COM interface? Did they handle this case correctly? My experience was that roughly half the time they did not - indeed, they often weren't aware that they had an implied contract to maintain the interface.


    This might not be you - you probably know better. I certainly hope that I know better. But to recommend not changing the assembly version number as a 'best practice' perhaps isn't the best of ideas.


  • By changing the file version, you still get to keep track of the abslute version without breaking an AssemblyBinding.

  • Robert, I understand that - however, in many cases, a code change may well be a 'breaking change', and without very intensive regression testing, not incrementing assembly versions is a dangerous thing to do. By not changing the assembly version, you are signalling that there are no breaking changes in your assembly. Are you 100% this is true?


    Microsoft fails on this measure even with QFEs (ie, QFEs sometimes break other dependencies, in unpredictible ways), and I've seen internal guestimates that they spend about $30,000 per QFE in testing. Can any of us make the same claim?


    Furthermore, Suzanne's suggestions are an attempt to avoid publisher policy redirects. If redirects are so broken, then Microsoft should be fixing the redirect issue, not advocating hacks to get around the way the Framework is architected.

Comments have been disabled for this content.