Solution: .Net Hell and Version Control, unstable, irreproducable bugs.

  • Thread starter Thread starter Anthony Berglas
  • Start date Start date
A

Anthony Berglas

What happens if you reference a System.Windows.Forms 1.0 when using a 1.1
CLR? Weird, unreproducable bugs deep within the runtime. Thats what.

But why would you want to do that? You wouldn't, of course. At least not
on purpose. But remember that assembly references now include the version
number burnt into them.

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.

And what happens if P refers to Q and S 1.0, while Q refers to S 1.1. Chaos
again. You obviously cannot have both versions in the same application
space (I hope).

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 we move from the sublime to the ridiculous.

DLL Hell 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?

Imagine if Windows was written in .Net (it should be -- like the Lisp
machines of old). Applying a software patch would do nothing unless you
also udated all the application version dependencies. And then we would
have a "clever" installer that did this automatically, sort of.

Maybe we'll look back fondly to the days of the bloated registry and DLL
Hell.
 
Upgrade to my previous posting:-

What happens if you reference a System.Windows.Forms 1.0 when using a 1.1
CLR? Weird, unreproducable bugs deep within the runtime. Thats what.

But why would you want to do that? You wouldn't, of course. At least not
on purpose. But remember that assembly references now include the version
number burnt into them.

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.

And what happens if P refers to Q and S 1.0, while Q refers to S 1.1. Chaos
again. Apparantly both S 1.0 AND S 1.1 are loaded into the same
application. Bad things will happend if P passes an S 1.0 object to Q.
(This is called "side by side" execution.)

The full story is very complex. You can override versions at either the
Application, Machine or Publisher level. The publisher can say "always use
1.2 instead of 1.1", but they may or may not do this. So what you actually
end up executing is not at all clear.

The bottom line is that in my case I had unexplainable bugs until I
carefully went through all the versions. 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 we move from the sublime to the ridiculous.

DLL Hell 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?

Imagine if Windows was written in .Net (it should be -- like the Lisp
machines of old). Applying a software patch would do nothing unless you
also udated all the application version dependencies using yet more config
files.

Maybe we'll look back fondly to the days of the bloated registry and DLL
Hell.
 
Thanks for this, but the article you point to only discusses the basics of
runing 1.1 and 1.0. It does not mention the other "Side-by-Side" issue of
different versions of a referenced assembly used by the same application.
Also the note about Visual Studio is not quite right -- because you can mix
them. Plus my Visual Studio 1.0 seemed to be trying to run on the 1.1
runtime.

Like most Microsoft articles, it vaguely covered the basics, but not the
hard issues.

I found Jeffrey Richter's book fairly good, although again it was a bit
vague on the hard issues.

Anthony
 
Back
Top