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:
"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."
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 22.214.171.124 has the implementation of foo() changed in? Not sure, are we? Can you even tell the difference between this 126.96.36.199 and that 188.8.131.52 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.