Introduction
Revision: According to Suzanne Cook below, apparantly all the framework .Net assemblies (not just MSCorLib) are a special case in which version numbers are ignored. But my experience below still stands, and certainly these problems will arrise with non-framework shared resources.
Do you have an unstable application with weird, unreproducable bugs (like I had)? Maybe you are suffering from ".Net Hell"?
As you will know, .Net incorporates the version number into the name of assemblies. So when you reference System.Windows.Forms you are actually referencing a specific version, say V1.0.5000.0 (for the new CLR 1.1), (or V1.0.3300.0 for CLR 1.0). There can also be multiple versions loaded in the same CLR at the same time.
But What happens if you get the references mixed up, say by using a System.Windows.Forms 1.0.3300.0 when using a 1.1 CLR? Weird, unreproducable bugs deep within the runtime. Thats what.
So suppose you have assembly A which references your assembly B which references .net assembly S 1.0. You now go through and upate A to .Net 1.1. But the reference from B is still to S 1.0. So now you have fun and games.
A confusing issue is that when you upgrade to Visual Studio 1.1 it not only upgrades your .sln file. It also silently upgrades all the references in your assemblies in that solution to refer to 1.1. So the problem does not always occur. And worse, if you just double click on a 1.0 .sln file, it opens Visual Studio 1.0, despite the file bindings, and so does not upgrade anything.
So, you need to be very, very careful about which versions each assembly in your application refernces, and you need to manually go through them an upgrade them.
Note that apparantly .Net will allow you to have both versions in the same application space, but that is not a good idea! And there are no errors or warnings raised. The lack of decent diagnostics is the key to a lot of Windows Hell in general.
So do we move from the sublime to the ridiculous?
Microsoft's .Net documentation talks a lot a bout "DLL Hell" which was a complete lack of control over version numbers. "DotNet Hell" is that All version dependencies are hard coded. Why cann't we have the obvious solution, namely that we normally refer to the Latest version, but have the Option to override?
Sure there are lots of configuration files that can be used to override versions at the application, machine and vendor configuration level. But what a complicated mess to have to be aware of just to fix a bug in a public assembly.
Maybe we'll look back fondly to the days of the bloated registry and DLL Hell.
Suzzane Cook adds some clarrifications below and refers to her excellent weblog. Apparantly "framework" dlls are treated as another special case (different from mscorlib). I only know as much as the documentation that I can find -- ie not very much at all.
But the bottom line for me was that I have a fairly simple 100% managed but multi solution application. No config files, only framework public dlls. And it was very unstable untill I reworked the version numbers which caused all bugs to disappear (at least the ones that weren't my own!).
