DLL HELL in .Net and Its Resolution With Versioning

DLL Hell is a very frequently used term in interviews. What is it and how does it occur?

In this article I'm going to share the reasons of its occurrence and the resolution.

DLL Hell



After having a look in the image above you can understand that two applications A and B, use the same shared assembly .

Now a few scenarios occur during production; they are:

1. I have two applications, A and B installed, both of them installed on my PC.
    
2. Both of these applications use the same shared assembly SharedApp.dll.
    
3. Somehow, I have the latest version of SharedApp.dll installed on my PC.
4. The latest SharedApp.dll replaces the existing DLL, that App A was also using earlier.
5. Now App B works fine whereas App A doesn't work properly due to the newer SharedApp.dll.

In short, a newer version of a DLL might not be compatible with an older application. Here SharedApp.dll is a newer version that is not backward compatible with App A.

So, DLL HELL is the problem where one application will install a newer version of a shared component that is not backward compatible with the version already on the machine, causing other existing applications that rely on the shared component to break. With .NET versioning we don't have the DLL Hell problem anymore.

Now the resolution of this is after introducing Versioning in .Net with shared assemblies. Which is placed in the GAC (Global Assembly cache). Its path is usually "C:\Windows\assembly" and the screen shot of the GAC in the following in image shows how it looks.

GAC Image



The GAC contains strong-named assemblies. Strong-named assemblies in .NET have 4 pieces in its name as listed below.

1. Name of assembly
2. Version Number
3. Culture
4. Public Key Token

If you look at the images above, you can find that Microsoft.Interop.Security.AzRoles assembly has version 2.0.0.0.

Each DLL has its own version number that describes it as in the following:



Now recall the DLL Hell problem with the newer face that uses versioning, as described in:

1. I have two applications, A and B installed, both of them installed on my PC.
    
2. Both of these applications use the shared assembly SharedApp.dll having version 1.0.0.0.
    
3. Somehow, I have the latest version (2.0.0.0) of SharedApp.dll installed in the GAC.
4. So, in the GAC we now have 2 versions of SharedApp.dll
5. Now App A uses its old DLL with the version 1.0.0.0 and App B works perfectly with SharedApp.dll version 2.0.0.0.

In summary, the .Net DLL versioning helped to resolve this DLL Hell problem.

Hope you enjoyed this demonstration.

Keeping Coding and Smiling.