dll hell equivalent in .NET?

[Nad]

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.

[smith]

Re: dll hell equivalent in .NET?

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

https://www.smithvoice.com

"Nad" <Nad@discussion s.microsoft.com > wrote in message
news:AC2D2A17-5D5D-4327-B6DE-B9D103B38EB3@mi crosoft.com...[color=blue]
> 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.
>
>
>[/color]

[Nad]

Re: dll hell equivalent in .NET?

Thank you for taking the time to reply.

I don't understand technically how different SP versions could cause a
deployment problem, after all the CLR checks for unique identity of each
component in the GAC by the component's strong name. Any how, I understand
your point. Why look for trouble when there is ample disk space.

Regards.


"smith" wrote:
[color=blue]
> 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" <Nad@discussion s.microsoft.com > wrote in message
> news:AC2D2A17-5D5D-4327-B6DE-B9D103B38EB3@mi crosoft.com...[color=green]
> > 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.
> >
> >
> >[/color]
>
>
>[/color]