DLL Hell

I l @ ve RuBoard

As most of us are aware of by now, one of the goals of creating Win32 DLLs was for code reuse. We are also painfully aware that the version of the DLL could make or break the application. New applications would ship and often contain a newer version of a DLL that another application would depend on and, of course, the new DLL would break existing software. The rules of COM tried to combat this problem through strict rules, but these rules were to be followed by developers and not enforced by any runtime system. As such, even applications that used COM components found that not all COM developers followed the rules, and software would crash when using different versions of supposedly the same component.

With .NET, Microsoft has chosen a new approach to solve the dreaded issue of DLL hell. The .NET runtime enforces versioning of components and even allows for side-by-side installation of components with different versions. Client applications then can choose which version of the DLL to use; by default, an application will load the version of the DLL to which is was originally linked during the initial release build. If a new version of a shared component becomes available, the application then can be configured to use the new version of the DLL or continue to make use of the current DLL.

I l @ ve RuBoard