Restrictions on registry-free COM

Recently, this registry-free COM technology was used in our work, that is, free registration of COM.

The COM component we provide will be used by multiple products, and these products may:

• Installed on the same machine
• The COM component used is of different versions.

In this way, if you use a common registered COM component, it will conflict with each other because of mutual coverage. If you are light, the function will go wrong and the heavy part will crash directly. This is the famous DLL Hell.

What is Registry-Free COM?

Free to register COM, which can also be called Private Assembly, Side-by-side Assembly, and Isolated Application. It is not a global shared component registered in the registry, but specially used for an Application. Let's look at the MSDN statement:

Registration-free COM is a mechanic available on the Microsoft Windows XP (SP2. NET-based components) and Microsoft Windows Server 2003 platforms. as the name suggests, the mechanisms enables easy (for example, using XCOPY) deployment of COM components to a machine without the need to register them.

In the past, loading a COM component started with the Registry, finding the DLL corresponding to a COM class and initializing it. How does one achieve this with the free registration of COM? In fact, it is very simple to write the information previously stored in the registry, such as these interfaces, COM classes, and corresponding DLL and Tlb, into a manifest file, then link the file to the Application using the COM component. The COM mechanism inside the operating system will load the COM component from the manifest information-obviously, this involves updating the COM mechanism, so only systems after XP support registry-free COM.

If you want to learn more about the working mechanism of registry-free COM, refer to the authoritative description of MSDN:

Isolated Applications and Side-by-side Assemblies

Here is a comprehensive example to show you how to create a registry-free COM component step by step:

Registration-Free Activation of COM Components: A Walkthrough

In addition, there is also a good article:

Simplify App Deployment with ClickOnce and Registration-Free COM

Advantages of Registry-Free COM

There are two main points:

• This avoids global sharing of COM components and avoids DLL Hell.
  MS is also called DLL Version Conflict:
  

  Compatibility problem. assembly sharing problems occur when an application installa version of a shared assembly that is not backward compatible with the previusly installed version. A solution to DLL versioning conflicts is to use side-by-side assembly sharing and isolated applications. with side-by-side assembly sharing, multiple versions of the same Windows assembly can run simultaneously. developers can choose which side-by-side assembly to use.

• Because you do not need to write the registry, the administrator privilege is not required during Applicaiton installation-Do you still remember the evil UAC in Vista?

Restrictions of Registry-Free COM

It should be said that the non-registration-free COM provided by Microsoft is already perfect for general applications and effectively solves the "stubborn" Problems in the COM component release ", however, because of our in-depth use, we will inevitably encounter some problems, which can also be said to be some of its defects:

• In a process, a Registry-Free COM Object is stored in the ROT (Running Object Table), but this Object cannot be obtained in another process.
  ROT is a global <CLSID => Object> map, which is used for inter-process communication. It is generally to register the objects to be shared in a process with RegisterActiveObject to ROT, and then get the object through GetActiveObject in another process. However, this does not work in registry-free COM. By checking the ROT, you cannot see the CLSID you registered. What's going on? The following is an explanation from MS:

  We haveRegisteredVs.ConfiguredCLSIDs. in non-sxs COM, generally the registered CLSID matches the configured CLSID. in SXS-based COM (plus some other instances, like certain kinds of DCOM) the two are different. because the same registered CLSID can appear twice in the same process from two different versions of a sxs component, the SXS machinery inserts twoConfiguredCLSIDs into the COM class DB for the processs. each sxs activation context has a map of {regclsid => conf-clsid-a} plus a lookup like {conf-clsid-a =>{ dll name, registered-clsid }}. they still represent the same object-if you did CoCreateInstance or GetActiveObject or any other mechanic-then you 'd get the right instance backBased on the active context at the time of the call. If inserting and fetching from the ROT pieces of code are in the "the same application", they use the same activation context and hence it works, but this is not true for cross-application as now the activation context are different and that's why we run into those errors and it doesn't support cross-process activation.

  Simply put, the CLSID put in the ROT is no longer the CLSID you defined. To allow different versions of the same COM component to coexist in a process, the COM mechanism modifies the CLSID internally so that it is based on the DLL and the defined CLSID of the object. In this way, the objects of different versions of the same CLSID are named differently, it can coexist in the same process, and thus can be split in the ROT area. However, it does not make sense to separate them in the ROT, because the main objective of the ROT is to cross-process, and in another process, I will never know what the CLSID you have modified is, and I will not be able to get the desired object. There is no better solution for this situation. There is only one workaround: RegisterActiveObject with a brand new CLSID to register COM objects (even if they do not have any relationship ), this CLSID will not be modified, so that this object can be successfully obtained from the ROT in another process.

• Microsoft also provides both in-process COM components (DLL) and out-of-process COM components (Exe). However, in the registry-free world, existing materials and experiments show that, only the COM component in the process is supported. This has brought us a lot of difficulties. The existence of the COM Server outside the process has its own reasons. Not every one of them can be converted to the COM component in the process, for example, the 32-bit external COM Server used to run 32-bit DLL on a 64-bit system-this is complicated and needs to be discussed in an independent article.