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.

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
eg and
egfree 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 entries?in 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 file.

Building for Reg-free COM
With Visual Studio.NET 2005, building registration free applications is simple. Before you open the FlashCards solution, however, you will have to register the WaveOut.ocx control. Somewhat ironically, although you can launch a deployed application without registering COM controls, you do have to register COM components on development machines where you’re building applications that use Reg-free COM?for now, Reg-free COM is strictly runtime.

Back at the command line, navigate to the sample code folder and type the following command:

   regsvr32 WaveOut.ocx

That command registers the component, so you can now load the FlashCards application from the /Reg directory into Visual Studio.

From the Reg/FlashCards folder, open the FlashCards solution file. In Solution Explorer, open the References folder. When I added the ActiveX control WaveOut.ocx to the application form (via Toolbox->Right Click->Choose Items->COM), VS added two references to the project: WaveOutLib and AxWaveOutLib. These two files are automatically generated by Visual Studio through a call to aximp.exe to provide a wrapper for the ActiveX control. Set the isolated flag to “True” to allow for Reg-free deployment (see Figure 2). You can select either DLL, as Visual Studio will update the other one to match automatically.

Figure 2. Set COM Component Isolation: Here’s the property setting to isolate an interop COM component for a Reg-free build.

Now, when you build (either release or debug) the FlashCards application, VS will also create an XML manifest file named FlashCards.exe.Manifest that contains the ClassID and type library information for the control?the same information that was previously stored in the registry.

Here’s a portion of the manifest:

                                                         7CQJz4x0edO3IsPI6RJ+BlX0m2M=                                 

With the manifest created, simply copying the release folder (using XCOPY) to any client will let that client use the control without any entries in the Registry. Copying the files is the only step required for interop deployment, but be sure to review the checklist in the next section before using Reg-free COM.

Reg-free COM Checklist

1. The end-user’s operating system must be Windows 2003 Server or Windows XP with Service Pack 2. Reg-free COM will not work on earlier OSs or earlier XP service packs.
2. Verify that the COM component is registered on the development box that does the build. The component must be properly registered for Visual Studio to generate the manifest information required to use Reg-free COM.
3. Do not use Reg-free COM unless you wish the component to be isolated. In other words, if you want to share the component with other applications, you must make sure it’s properly registered on the target machines.
4. Test on a clean machine (one where the components are not registered). That’s because you won’t get a warning if Reg-free COM deployments are actually accessing the registered version of a COM control. A clean machine is the best way to verify that an application using Reg-free COM is functioning as expected.
5. Think through dependencies. For Reg-free COM, use only components that can function in isolation. For example, graphics components make good candidates for isolation, but system files do not.
6. Keep it legal. Third-party COM components (including Office) are not typically redistributable royalty-free.