The extent of dll-hell symptions on machines with multiple Frameworks is
debated (Itr's not exaclty dll-hell but a similar deployment problem comes
up when different users have different service pack versions of the same
base framework such as 1.0 with the latest SP broke a lot of remoting
because it required permission configs to use syntax that was introduced in
1.1)
However, as I've seen it from a number of releases over the past 3 years,
the general old time issues are greatly reduced it you don't GAC your
components and instead release all components to be deployed to the same
folders as the executables. Back in the day hard drives were very expensive
and so the registry and shared ActiveX dlls and ocxes made sense (and we
laughed at how Apple forced complete packages).
Now drivespace is far less expensive (Hotmail gives each email acount 2GB -
that would have caused heart attacks back in 1993 when Win95/NT4 were being
designed) so including all your components is usually far more acceptable.
As I see it, the advised practice is to *not* GAC unless you absolutely have
to minimize the footprint. With that prictice the dll-hell is only a matter
of those varying MS service packs on the base.
robert smith
kirkland, WA
www.smithvoice.com
"Nad" <Na*@discussions.microsoft.com> wrote in message
news:AC**********************************@microsof t.com...
Hello,
dll hell has been eliminated in .NET using assembly versioning.
I am new in .NET and would like to know if there is any
dll-hell-equivalent
in .NET Windows or Web development environments that need to be
addressed/aware of?
Thank you.
