Avoid DLL Hell with Registration-free COM

eusable, dynamically linked components are generally a good idea, because they allow you to leverage code and save memory rather than reinvent the wheel. But with thousands of developers leveraging thousands of native DLLs—and no OS-enforced systematic control of versioning or installation, developers often overwrite their own and others' DLLs during installation, a process colloquially known as "stomping."

One might hope that those days are behind us, given .NET framework's Global Assembly Cache (GAC), assembly manifests, and managed code components, but the fact is if you still develop with VB6 Controls, the C++ Active Template Library (ATL), or ActiveX, your interop applications might still be contributing to someone's DLL hell. DLL hell, is a common description of what happens when an application loads and executes code from a DLL whose name is the same as a referenced DLL, but whose behavior differs from the developer's expectations. Most often, this happens when an installer copies and registers an older version of a DLL, replacing a newer version of that component or overwriting a different one with the same name, or—less commonly—by introducing a backward-breaking change in a newer DLL.