Explain how Dll hell is overcome in .net with example

[nandini_net_in]

Hi,

I have broswed the web and tried to understand the concept of Dll hell and how it has been overcome by .net, but still not clear as it says that can have different versions of assembly running side by side, what does this mean. Can someone explain with coding so that I can and see my self. Does this refer to the different versions of framework or the different versions of visual studio like 2003 or 2005 or are they talking abt the different versions of the project/application..I' so confused. So kindly explain with a sample code if neccessary.

Thanks!.

[brin351]

"different versions of assembly running" means different versions of .net framework like 1.1, 2.0, 3.0 on the same machine and you can have VS2003 and work with .net1.1 and VS2005 with 2.0,3.0

It's up to your project design if you let people install multipul versions of your program or make them upgrade an existing one.

[nandini_net_in]

Hi,

Thanks! for the info. I also want know if assembly is nothing but the .dll that gets created when we build the application. Say for example the project/application name is TOAST, then toast.dll get created in the bin directory in the root folder of TOAST. Correct me if I'm worng.

[RobDog888]

Thread Moved

[Hack]

I believe the assembly is contained within the framework itself and not your application.

[techgnome]

"different versions of assembly running" means different versions of .net framework like 1.1, 2.0, 3.0 on the same machine and you can have VS2003 and work with .net1.1 and VS2005 with 2.0,3.0

It's up to your project design if you let people install multipul versions of your program or make them upgrade an existing one.

That's not quite what it means either.... If I create a dll in .NET using FW2.0....and deploy it with an app.... then later I take that DLL.... make major mods to it.... then deploy it with ANOTHER app....the two DLLs will happily co-exist side-by-side on the same machine with out affecting each other's apps. THis is because the DLLs are deployed within the app's directory. And neither are actually registered with the system (as the older AxtiveX DLLs were). Since they are not registered with the system, they don't know about each other, and therefor do not create any conflicts with each other.

The version of the FW doesn't really play into this, it's really more about the versions of the assembies themselves.

-tg

[Hack]

tg (or anyone else): Is this an accurate statement?

I believe the assembly is contained within the framework itself and not your application.

[techgnome]

Not really.... when you build an assembly, it exists where it does... usually with the app that uses it. Now, if you install it into the GAC (Global Asseembly Cache)... then it has the appearance of being framework, since ANY app at that point could reference it (when you right Click "Add Reference" and click the .NET tab.... everything that's listed is in the GAC) ... And it is possible to have two version of the same assembly in the GAC, provided the Assembly version is different. - that is how the different frameworks are able to co-exist....

-tg

[Hack]

Ok....I think I understand. Thanks for clearing that up.

[brin351]

Yes thanks techgnome for your insight.

[nandini_net_in]

Hi All,

Thanks for all the inputs. But w.r.t my seccond question that is the assembly the dll created in the bin directory of every application or is it a diffent one. How do I create another different version of assembly for the same application and also how to I refer this in another application?. Kindly explain.

Thanks again.

[RobDog888]

The default location is the bin folder but its user selectable so it may be different.

[techgnome]

Hi All,

Thanks for all the inputs. But w.r.t my seccond question that is the assembly the dll created in the bin directory of every application or is it a diffent one. How do I create another different version of assembly for the same application and also how to I refer this in another application?. Kindly explain.

Thanks again.

First, it's generally not a good idea to have two versions of the same DLL in the same folder... how would the app know which one to use if they both have the same namespaces and classes in them. But if you are trully hell bent on doing so, you would by giving them different names.... myDllv.1.0.0.dll and myDllv1.2.0.dll..... but if they both hold the same class "MyClass" ... how does your app know which one to load? It doesn't.

As for other apps, same deal, you set a reference to it. Normally, most DLLs when referenced, and are not part of the GAC, get set with the "Copy to Local" to true. Which means, now your app gets a local copy of that DLL... even if it changes, if you don't recompile your app.... and you don't copy the newer version into the app folder, it will use the one right inthe app folder, which is the older version. Maybe this is what you want... maybe it isn't.... that's up to you.

-tg