DLL Hell was a phrase coined many years ago to describe a problem that is inherent in Windows method of sharing code: the Dynamic Link Library. In this and the next newsletter, I will outline what causes DLL Hell and how .NET solves these specific issues. I will start by describing the underlying causes of DLL Hell and explain .NETs solution in the next newsletter.
The "D" in DLL refers to the the fact that the linking of libraries to a process
occurs dynamically at run time rather than statically by the compiler. It's
true that a developer can statically link to an import library, but the DLL
is still linked at run time. The reason is because the import library gives
the compiler enough information to build an Import Address Table, which contains
information about the DLL and the function to be imported. The compiler directly
calls to the DLL functions to entries in the IAT. At run time, the
Win32 function is called to load the DLL and the IAT entries are overwritten
with the actual address of the functions in the DLL. The developer can also
LoadLibraryEx to explicitly load the DLL and then call
to get the address of the function; this involves messing around with function
pointers, but it does give the developer a better opportunity to handle the
situation when a DLL is missing or does not have the requested function.
Notice that both of these mechanisms use
LoadLibraryEx. DLL Hell occurs
LoadLibraryEx is passed the name of the DLL to load. This
can be an absolute path, indicating a DLL in a specific folder, but typically
it is just the name of the DLL. If the path is omitted, then
will use an algorithm to locate the DLL (take a look in the entry for this function
in the MSDN library for complete details), which includes the Windows system
folder (for shared DLLs) and the folders in the PATH environment variable. The
problem is that
LoadLibraryEx loads a DLL by name and although PE (portable
executable) files can have a version resource, this is not part of the name.
Two versions of the same DLL must have different names, otherwise
could load the wrong version of a DLL, or it could even load a totally different
DLL that has the same name.
COM helps because the actual location of a library is stored in the registry and the client code never uses DLL names and paths, but instead refers to class names (CLSIDs), and the COM system resolves the class name to a DLL path through a registry lookup. The strict rules of COM are such that if a class changes, then its CLSID should also change, and so the DLL housing the class should change as well. However, people broke these rules, so DLL Hell persisted into COM code (if developers had followed the COM rules, then DLL Hell would have gone away). COM's reliance on the registry was also a problem because it meant that the library would have to be installed before use, and uninstalled when the application was removed.
So, the problems of using Win32 DLLs come down to these issues:
LoadLibraryExloads DLLs by name and pays no regard to the version of the file requested.
- PE file names do not have an explicit version component and so different versions of the same DLL coexist badly: A later installed version will overwrite an earlier installed version in the same folder.
LoadLibraryExhas a search algorithm to locate DLLs and, although you can tweak this algorithm, it's largely an all or nothing affair: You either use it or you don't. If the algorithm does not work for you, then you have to give an absolute path. If the algorithm fails, there is no information about where the algorithm has searched to allow you to rectify the problem.
- If you want to share a library between applications, you have to place it in a folder that all applications have access to (typically the Windows system folder is used) and this means that only one version of this library can exist.
There were ways to get round these problems, but basically they were just small fixes to a flawed process. To get round all of these problems, the .NET team came up with an entirely different mechanism called Fusion, which I will describe in the next newsletter.
As a postscript, the DotNet Developer Group in the UK (www.richplum.net) has recently had its inaugural meeting at Microsoft's Thames Valley Park campus. I spoke at that meeting, and I'll speak at some of their other meetings later this year. If you're in the UK, come along to one of these user meetings and listen to some great talks about .NET
Richard Grimes speaks at conferences and writes extensively on .NET, COM, and COM+. He is the author of Developing Applications with Visual Studio .NET (Addison-Wesley, 2002). If you have comments about this topic, Richard can be reached at firstname.lastname@example.org.