.NET and DLL Hell

“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 .NET’s 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 LoadLibraryEx 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 call LoadLibraryEx to explicitly load the DLL and then call GetProcAddress 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 mainly because 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 LoadLibraryEx 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 LoadLibraryEx 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:

1. LoadLibraryEx loads DLLs by name and pays no regard to the version of the file requested.
2. 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.
3. LoadLibraryEx has 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.
4. 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 [email protected].