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 DLLsand 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, orless commonlyby introducing a backward-breaking change in a newer DLL.
In either case, applications that were working fine suddenly break, either because the older DLL doesn't support the functionality of the newer DLL that the applications expected to load, or because the newer DLL breaks functionality that was working fine in a previous version.
But if your clients run Windows XP SP2, Windows Server 2003 or newer Windows OSs, Microsoft's introduction of Registration Free COM (Ref-free COM) can reduce or eliminate DLL conflicts. This article provides an overview of using Reg-free COM with managed .NET code, and offers a development scenario that illustrates deploying a COM component with XCOPY.
Reg-free COM In Action
Here's a quick peek at Reg-free COM in action.
To build the solution for the reg-free COM test, unzip the downloadable code associated with this article to a local drive. First, open the WaveOutComControl solution and build the solution. Next, open the FlashCards solution in the /FlashCards_CSharp directory and rebuild that solution. You will see one warning, which you can safely ignore. From the debug directory of the FlashCards solution, copy FlashCards.exe twice, once to the /Reg directory and again to the /RegFree directory.
Visual Studio registers the included WaveOut.ocx control automatically when you build the solution. To clear the registry entries and set your machine up for the Reg-Free demonstration (mimicking a client machine where the control would not be registered), go to a Visual Studio .NET command prompt and type the following command to unregister the control: regsvr32 /u WaveOut.ocx.
After performing these steps, in the \reg and \regfree directories you'll have two copies of the sample application, "FlashCards." FlashCards is a C# .NET 2.0 Windows Forms application that presents Spanish words and their English counterparts. It reads the words from an XML file called lesson1.xml via an XPATH query and randomly presents the words to end users. If present, FlashCards uses the WaveOut.ocx ActiveX control to play the associated word .wav file, giving FlashCards users the opportunity to hear the word with native pronunciation. WaveOut.ocx is a native COM control written using C++ and MFC. The sample application demonstrates how to use this control without creating or modifying any registry entriesin other words, registration-free. Without altering any existing registry entries or overwriting any existing DLLs, you'll see how Reg-free COM lets supporting versions of Windows load and use multiple copies of identically-named DLLs.
The /Reg directory is set up as a standard "old-COM-style" application executable, FlashCards.exe, which depends on WaveOut.ocx being registered as a COM object in the registry. In contrast, /RegFree contains the same sample application, but built the Reg-free COM way. A quick comparison of the two directories reveals that /RegFree contains a file named FlashCards.exe.Manifest which I'll discuss later.
Navigate to the /Reg directory on the command line and attempt to run our sample application: Flashcards.exe. Because of the COM dependency, you'll get the error shown in Figure 1.
|Figure 1. COM Lookup Exception: This is the standard error message that results when an application calls an unregistered COM component.|
Remember, at this point, (after unregistering the .ocx
control earlier), you've run no installer that registered the component, nor have you manually registered the control with REGSVR32. Consequently, the Native Assembly Loader complains that the control referenced in the FlashCard program is not registered.
Now, step into the /RegFree
subdirectory and run FlashCards.exe
. This time, the application runs without the COM error. When the application opens, use the toolbar to open the lesson1.xml
file. For any word, you should be able to press the "Play Word" button to cause the ActiveX control to play the associated .wav
|Author's Note: The ActiveX control used in the /Regfree directory is exactly the same as the one used in the /Reg directory, but we've invoked it the Reg-free way!