Tuesday, June 24, 2003 7:28 PM jerdenn

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.

Filed under:

Comments

# Jerry Dennany's Occasional Clue

Tuesday, June 24, 2003 7:28 PM by TrackBack

Jerry Dennany's Occasional Clue

# Paul Wilson's .NET Blog

Tuesday, June 24, 2003 7:28 PM by TrackBack

Paul Wilson's .NET Blog

# re: When to Change File/Assembly Versions?

Tuesday, June 24, 2003 10:49 PM by Robert McLaws

Versioning Suggestions in .NET Welcome Jerry. Check that out and tell me what you think.

# Why can't you use the file version to identify the build?

Wednesday, June 25, 2003 4:52 PM by Matt Griffith

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.

# re: When to Change File/Assembly Versions?

Thursday, June 26, 2003 10:11 PM by Jerry Dennany

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.

# re: When to Change File/Assembly Versions?

Friday, June 27, 2003 2:35 AM by Robert McLaws

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

# re: When to Change File/Assembly Versions?

Friday, June 27, 2003 11:32 AM by Jerry Dennany

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.

# re: When to Change File/Assembly Versions?

Wednesday, July 09, 2003 5:43 PM by Suzanne Cook

Hey, I've been misunderstood! Here's the quote again (original at http://blogs.gotdotnet.com/suzcook/PermaLink.aspx/cc6428d6-69fb-4f05-8f18-65f3eac85274 ) :

"In general, I recommend keeping non-shipping assembly versions the same [...]"

Note that I'm talking about non-shipping versions here. In the next paragraph, I went on to talk about shipping builds, and how they require a separate decision.

All of the comments about dll hell apply to 'shipping' builds, not the daily internal build env. If you have a partner taking drops of daily builds, they're going to want the new stuff - they won't want to continue to bind against the old drop (otherwise, why take a drop?). That means that they will rebuild and/or re-config in order to run the new stuff - breaking changes and all. So, they will get the exact same dll hell whether you change your versions or not, because they will run against the new code, regardless of its version.

So, given that, I stand by my recommendation for the non-shipping environment, for the reasons in my original blog entry. If you don't think so, you haven't been on the receiving end of a partner drop with new assembly versions! It is pain all around, and not necessarily as easy to debug as a FileNotFoundException (sometimes, that exception is caught). It has been my personal experience that it is not worth it in the dev env. For this scenario, there are no benefits to changing the assembly version that (a) changing the file version and (b) changing the assembly version right after shipping don't cover - all you get is pain.

However, I'm more likely to agree with Jerry's comments when applied to a shipping build. It is definitely more safe for compatibility to increment the assembly version for new shipping builds. But, that is not the only consideration. If the new fix is required for security or some other must-have, the publisher may not want to give anyone the option to use the original version. This decision should be carefully considered on a case-by-case basis.

Leave a Comment

(required) 
(required) 
(optional)
(required)