F.3 What is DLL hell?

Probably unheard of in the Java world, 'DLL hell' is a common problem faced by COM developers. A DLL can be treated like a library component which contains methods to be used by other DLL or EXE files. In the COM world, you can have many unrelated programs calling methods from the same shared DLL file. Now, the rule is that you can update a DLL by releasing a newer version of the DLL with the same name . That means that your new DLL file must contain the same method signatures as the older one so that they can still be invoked by current applications using that shared DLL. You can change the encapsulated logic within the existing methods, or add in new methods, but the old method signatures must remain intact if existing applications are not to be broken.

In the COM days, DLLs could not be versioned “ you might have been able to deduce the relative newness of a DLL by examining its date, but that was it. When a new version of MySharedLibrary.dll was to be rolled out, you usually replaced the existing one on your local PC with the newer file. Theoretically speaking, existing applications dependent on version 1 should not break, but the truth is that many problems arose due to incompatibility . What's worse is that some installation programs simply overrode shared DLLs in the system folder without bothering to check if the date of the existing DLL was newer than the one being installed (this will definitely break newer applications using the newer version of the shared DLL previously installed). ^[3]

^[3] Of course, such brutal installation programs can only be written by lousy programmers. But, alas, the world is full of lousy programmers.

This scenario is popularly known as 'DLL hell' in the Microsoft world.

And that's also why Microsoft has designed .NET assemblies to be versionable. Shared assemblies of different versions sharing the same name can exist in the same folder. Furthermore, applications using these shared assemblies are tied to specific versions of the assemblies. So, in the .NET world you can have version 1 and version 2 of the MySharedLibrary.dll shared assembly existing in the same folder on the same server. They have the same name but different version numbers recorded in their manifest file. So, MyApplication1.exe , which uses version 1 of MySharedLibrary.dll , will continue to use that version even when some installer puts version 2 of MySharedLibrary.dll into the system. The additional hard disk space required to store multiple versions of a .NET assembly is relatively small and definitely worth the trouble caused by DLL hell of COM times.

Another improvement of .NET assemblies over traditional COM DLLs is the inclusion of a hash code in the manifest. The assembly will work only if the .NET runtime has verified that the assembly hasn't been altered . An alteration will produce a new hash code which mismatches the one recorded in the assembly's manifest.