DLL HELL problem with an example

Let us try and understand DLL HELL problem with an example. Please refer to the image below. If you want to know how dll hell problem is solved in .net, you can read this article.




1. I have 2 applications, A1 and A2 installed on my computer.

2. Both of these applications use shared assembly shared.dll

3. Now, I have a latest version of Application - A2 available on the internet.

4. I download the latest version of A2 and install it on my machine.

5. This new installation has over written Shared.dll, which is also used by Application - A1.

6. Application - A2 works fine, but A1 fails to work, because the newly installed Shared.dll is not backward compatible.

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 donot have DLL HELL problem any more.

How is the DLL HELL problem solved in .NET, is another very important .net interview question. Click here to read.



Please read What is dll hell? interview question, before proceeding with this article.


In short, the dll hell problem is solved in .NET by signing the shared assemblies with strong name. Please follow this article, to understand the process of strong naming an assembly.

In dot net all the shared assemblies are usually in the GAC. GAC stands for Global Assembly Cache. The path for GAC is C:\[OperatingSystemDirectory]\assembly. For example on my computer the path is C:\WINDOWS\assembly. The image below shows the shared assemblies in the GAC.

Only strong named assemblies can be copied into GAC. Strong named assemblies in .NET has 4 pieces in its name as listed below.
1. Simple Textual Name
2. Version Number
3. Culture
4. Public Key Token


All these four pieces put together, is called as the fully qualified name of the assembly. In the GAC image above Accessibility assembly has a version of 2.0.0.0.

Now consider the example below:
1. I have 2 applications, Application - A1 and Application - A2 which relies on the shared assembly Accessibility.dll (Version 2.0.0.0) as shown in the image below.

2. Now, I have a latest version of Application - A2 available on the internet.
3. I download the latest version of A2 and install it on my machine.
4. This new installation copies a newer version of Accessibility.dll into the GAC with version 3.0.0.0.
5. So, in the GAC we now have 2 versions of Accessibility.dll.
6. Application - A1 continues to use Accessibility.dll (version 2.0.0.0) and Application - A2 uses Accessibility.dll (version 3.0.0.0)
7. So, now the assemblies are able to reside side by side in the GAC. For this reason dot net assemblies are also said to be supporting side by side execution.