When more than one application sharing same DLL in .net (C#, VB.Net etc.) and if we replace existing dll with newer version then some application doesn't work properly due to this newer version of dll. In short, a newer version of a DLL might not be compatible with an older application. Such scenarios called DLL hell problem in .Net.

How to resolve DLL hell problem

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.

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"

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

Name of assembly

Version Number

Culture

Public Key Token

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:

I have two applications, A and B installed, both of them installed on my PC.

Both of these applications use the shared assembly SharedApp.dll having version 1.0.0.0.

Somehow, I have the latest version (2.0.0.0) of SharedApp.dll installed in the GAC.

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

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 summary, the .Net DLL versioning helped to resolve this DLL Hell problem.