Home > DeveloperSection > Blogs > DLL HELL Problem in .Net

DLL HELL Problem in .Net

0 Comment(s)
 1663  View(s)
Rate this:

DLL HELL Problem in .Net

In this blog, I’m explaining the dll hell problem in .net

 DLL Hell refers to the set of problems caused when multiple applications attempt to share a common component like a dynamic-link library (DLL) or a Component Object Model (COM) class. In the most typical case, one application will install a new version of the shared component that is not backward compatible with the version already on the machine. Although the application that has just been installed works fine, existing applications that depended on a previous version of the shared component might no longer work. In some cases, the cause of the problem is even more subtle.

For example

 Consider the scenario where a user downloads a Microsoft ActiveX® control as a side effect of visiting some Web site. When the control is downloaded it will replace any existing versions of the control that were present on the machine. If an application that has been installed on the machine happens to use this control, it too might potentially stop working.

Solution of Dll-Hell Problem 

This problem of dynamic link library (.dll) is resolved through Versioning.


Versioning is the technique to provide version to the .dll to prevent them from replacement. Each assembly has a version name called compatibility version, also each reference to an assembly (from another assembly) includes both the name and version of the referenced assembly. The version number has four numeric parts (e.g. Assemblies with either of the first two parts different are normally viewed as incompatible. If the first two parts are same but the third is different, the assemblies are deemed as may be incompatible. If only the fourth part is different, the assemblies are deemed as compatible.

For example, DLL name template: Dll_name_xx.dll where xx is the number of the DLL version. Sometimes it is required to make big changes in the DLL, which break its backwards compatibility. In this case, the new name should be assigned to the DLL. While an installation to an OS, a new DLL, the old one will not be removed and clients compiled with it will still use it. At the same time, clients compiled with the new DLL will use the new one.

Don't want to miss updates? Please click the below button!

Follow MindStick