The Dll Hell problem is mostly
related to Win32 code, the further back in time you go the worse it was. DLL Hell, is kind of conflict that occurred
previously, due to lack of version supportability of dll for (within) an application.
Previously, if you had deployed any dll for particular application, and in
between you made some changes or provide some more functionality within that
application or enhance your application
and you deploy new dll or override existing dll, in this case our old module
which was/were running fine with previous dll, may behaves improperly because
of new dll deployed. This called dll Hell. This is no more exist in dot net
because of different version supportability of dll, it means old process worked
with old dll only and respond in exact manner, and new process which starts
after new dll deployed uses(executes with) new dll and respond to user.
DLL Hell: -
This is a problem in loading a
specific dll (class id, version number, path etc). For example, if I
build test.dll v1.0.0.0 and deploying it in c:\MyProg. My application App1 and
App2 are using the methods in that dll. And there is a requirement to change
something in App1 and I supposed to change test.dll also for the same
requirement. Once I finished with all my changes, I will be deploying them in
the appropriate locations. Now, the older dll will be overwritten. And my App2
will look for test.dll of older version and since it is not there it will not
work. This is a scenario for dll hell issue.Net Framework provides operating
systems with a Global Assembly Cache. This Cache is a repository for all the
.Net components that are shared globally on a particular machine. When a .Net
component is installed onto the machine, the Global Assembly Cache looks at its
version, its public key, and its language information and creates a strong name
for the component. The component is then registered in the repository and
indexed by its strong name, so there is no confusion between different versions
of the same component, or DLL.