No End to DLL Hell!

Experiences

When you start your program running Windows XP, you may encounter one of the following messages:

"Unable to execute program"

or:

"Error Code: 0xC0150002 : The application failed to initialize properly. Click on OK to terminate the application."

Or even other messages, none of which are particularly informing about the cause of the problem.

If you are lucky, you'll come up with the idea to look into the Systems Event log (not the applications event look as somebody might guess). And yes, there may be a bit more information:

"Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system."

or:

"Component identity found in manifest does not match the identity of the component requested."

That's better, but it still doesn't tell you what version it was searching, and why it didn't use a different version, existing on the system. On a machine that I just reproduced this message, four similar versions of this very DLL exist in the side-by-side repository:

8.0.50727.1433
8.0.50727.3053
8.0.50727.4053
8.0.50727.42

The version requested was:

8.0.50727.762

I know that because I wrote the program and I inspected the manifest file used to link the program. I would, otherwise I'd have no idea what version is needed.

Things are better with Windows 7: System messages are more informative and starting with Windows Vista a new tool has been introduced: sxstrace which is designed to retrieve information about the root causes. To use sxstrace:

1. Start sxstrace in logging mode
2. Reproduce the problem
3. Stop sxstrace logging
4. Parse the created log file and convert it to human readable information

Sometimes this works, sometimes it doesn't. In any event it is a tool that the typical user will be unable to handle. A support tool may collect entries from the systems event log and transmit them to the support center -- but it isn't able to use sxstrace. That's a task for a administrator. If you managed to run sxstrace successfully, the output is some diagnostic text that explains in more detail what the problem is. But it still won't tell you, where to find the exactly required DLL. Microsoft used tohave a page that helped to locate specific DLL versions, but alas, this service has been terminated.

So far the program concerned still can not be started by Windows. The only solution is to "somehow" find the needed DLLs and install them. If this "somehow" does not work, the program can not be used at all.

Consequences

The more assemblies a program uses, the more conflicts may occur and in many cases more size is required for the installer as well as on disk. A DLL would save disk space, if it is used by a large number of applications. But in practice Microsoft now ships so many different assembly versions, that they increase disk space used instead of saving disk spaceit.

Table 1 shows the most typical ways, a application is assembled and their consequences.

[Click image to view at full size]

Table 1

Solutions

To avoid DLL-Hell in 2010, the best way is:

Don't use public DLLs or assemblies at all.

Include all DLLs privately in the applications bin-directory and use private assemblies as far as possible if assemblies can not be avoided.

The best way to defeat all DLL conflicts is don't use any DLLs at all, but use static libraries instead. Its also possible to bypass the whole side-by-side and all assemblies, if desired. By default, Visual Studio per creates a manifest file for your project, but its easy to remove this in the Project settings and to work the old way, just using the DLLs in your applications folder.

And, of course, none of these options may not be practical for all applications -- for large applications DLLs are a way to keep the executable file small and loading fast, and also to keep things maintainable without reinstalling the whole application.

If in question, statically bound libraries are much better, even if they may cause some redundancy. Also redundancy is not avoidable when different thrid-party DLLs require different versions of one and the same Microsoft DLLs.

DLL-Hell in 2010

Assume you have a new great tool --say, the side-by-side manger that resolves all conflicts and keeps track about everything, if installed properly. That's an improvement. But shouldn't there be some fallback mechanism that makes it possible to get things running? Shouldn't it be possible to use a existing DLL of very similar version that is existing, instead of denying a program to run? The latter is a catastrophe for users and for support (if existent). This seems especially hard to understand in the case of a long concluded part such as the C standard library.

And shouldn't there be more straight and distinct information to vendors and to system administrators? Experienced administrators who were confronted with 0xC0150002 in my presence had no idea how to proceed. Amusingly, Microsoft apparently published an article The End of DLL Hell a while ago, but all links to it (even those on www.microsoft.com) point to a page containing the text "This content has been removed".

It is worth noting that DLLs no longer save disk space. In fact, the opposite is the case. If you have a look into the side-by-side repository (found in Windows' WinSXS directory), you will find, that its 5 GB on Windows 7 and even 7 GB on Windows Server 2008, containing 40.000 files with numerous versions of roughly all Microsoft Libraries. That's about 50% of the disk space used by Windows in total. We were needing s solution, but we created a monster.

Stefan is founder of www.RED-SOFT-ADAIR.com, a company that rescues software development projects in a technical crisis. He can be contacted at StefanWoe@gmail.com