DLL HELL in .NET

DLL HELL in .NET

DLL Hell is most frequent word during the interview session. Why it is and the reason of its occurrence.

In this article I’m going to share the reason of its occurrence and the resolution.

DLL HELL:

 

After having a look in the above image you can understand that two application A and B are using the same shared assembly

.

Now few scenarios come in front of us during the production time.

1. I have two applications, A and B installed, both of them installed on my PC.
2. Both of these applications use shared assembly SharedApp.dll
3. Somehow, I have a latest version of SharedApp.dll and installed on my PC.

4. The latest SharedApp.dll overwrite the existing .dll, Which App A was also using earlier.

5. Now App B works fine while App A doesn’t work properly cause to the newly created SharedApp.dll.

In short a newer version of .dll is not compatible with Old app .Here SharedApp.dll is with new version which is not backward compatible with App A.

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

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

GAC Image:

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 into 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 which describes as like below:

Now recall the Dll Hell problem with newer face with versioning concept.

 

1. I have two applications, A and B installed, both of them installed on my PC.
2. Both of these applications use shared assembly SharedApp.dll having version 1.0.0.0.
3. Somehow, I have a latest version (2.0.0.0) of SharedApp.dll and install It into GAC.

4. So, in the GAC we now have 2 versions of SharedApp.dll

5. Now App A uses its old dll with version 1.0.0.0 and App B works perfectly with SharedApp.dll version 2.0.0.0.

In summarize words .Net .Dll versioning helped to resolve this DLL Hell problem.

Hope you enjoyed this demonstration.

To learn more about MVC please go to the following link.

MVC Articles

Thanks.
Keep coding and Stay Happy

Categories: C#