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 v18.104.22.168 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.