Resolving "DLL Hell" Problem for ActiveX Components

In computing, DLL Hell is a term for the complications that arise when working with dynamic link libraries (DLLs) used with Microsoft Windows operating systems, particularly for legacy 16-bit editions which all run in a single memory space. While the phrase is Windows-specific and a derivation of the general cross-platform phrase Dependency Hell, the rhyme DLL Hell makes its use popular for discussing a general Windows-related dependency hell case. DLL Hell can manifest itself in many different ways; typically applications do not launch or fails to work correctly. Applications on modern versions of Windows suffer less from this issue following the introduction of the .NET Framework, registry-free COM and features in the operating system that prevent system files from being overwritten. Because COM components are usually implemented in the form of DLL s and registration allows only a single version of a DLL, they are subject to the DLL Hell effect. Moreover, using multiple builds of same ActiveX component would cause licensing problems as the GUID is same for all of them. Registration-free COM capability eliminates the problem. The following solution helps you to reduce this problem to a greater extent. Ideally, when we deploy an application, we install the required OCX to C:\Windows\System32 and register it so that it can be found by any application. This would work, but if you have multiple applications using different versions of the same OCX on the same machine, you will still see conflicts for whichever application is using the earlier version of the OCX. Alternative solution is to install to a local folder such as C:\Program Files\Mindjet and skip the registration of the OCX. Instead of this, you may use a .local file instead. Following steps summarizes the solution to the above problem for an application using VSFlexGrid:

1. Develop and build your application as normal.
2. Create a blank file with the same name as your exe, but with a .local extension. Notepad works perfectly for this. For example: For an application named myapp.exe, create a blank file with the name myapp.local (replace the .txt extension with .local).
3. Deploy myapp.exe, myapp.local, and the VSFlexGrid dependencies to the same directory.
4. Do not register the VSFlexGrid dependencies.

This should help you in resolving this problem to a greater extent. Alternatively, it will require manually placing same version of ocx/dll's on your machine for all the applications using that specific OCX.