Home Library Learn Downloads Support Community
Sign in | United States - English | |
0 out of 2 rated this helpful - Rate this topic

Creating Registration-Free COM Objects

Activation contexts enable COM objects to be used without requiring that they be registered. This enables your application to have multiple components with different functionality based upon their version rather than their registry information. Multiple components can expose the same COM object with the same GUID but have different functionality based on the version.

When an application requests a GUID from CLSIDFromProgID, COM first searches for the mapping from progid to CLSID in the active activation context. When an application uses CoCreateInstance to obtain an instance interface pointer, COM searches in the active activation context to find which DLL will host the CLSID. If the activation context does not contain the required information, COM then searches for the information in the registry using the usual method.

Note that because activation contexts are per-thread, COM marshals the activation context of the creating thread over to the host thread and activates it before calling LoadLibrary or DllGetClassObject on the host thread. This functionality is already present in Windows, client code is not required to do anything to implement this.

COM classes can be exported by hosted components without going through the registry. Multiple components can expose the same ProgID for different COM objects, and your hosting application should only find the proper activation context and then use CLSIDFromProgID and CoCreateInstance to get the hosted object's interface pointers.

 

 

Send comments about this topic to Microsoft

Build date: 2/3/2012

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Note about Side-by-side DLLs that are also statically linked
Suppose you have x.exe which makes use of COM components from a.dll and b.dll via CoCreateInstance (traditional COM so to speak). However, a.dll also statically links against b.dll, such that b.dll is always loaded whenever a.dll gets loaded.

If side-by-side COM via the manifest is not used, then a.dll and b.dll will typically only be loaded once. Both can be debugged fine. No issues.

However, if side-by-side COM via the manifest gets used, i.e. the following was added to x.exe.manifest:
<file name="a.dll">
<comClass clsid="{xxxxx-xxxx-xxxxx-xxxxx}" threadingModel="Apartment"/>
</file>
<file name="b.dll">
<comClass clsid="{xxxxx-xxxx-xxxxx-xxxxx}" threadingModel="Apartment"/>
</file>

Then the following may happen as a result of CoCreateInstance calls:
b.dll gets loaded (because of CoCreateInstance calls)
....
a.dll gets loaded (because of CoCreateInstance calls)
b.dll gets loaded (because of static linking)
The Visual Studio debugger output window shows that the same b.dll gets loaded twice (it never got unloaded). It is also unable to debug it, even though it says symbols have been loaded etc. This is an issue if a.dll and b.dll contain Fortran code that rely on shared structures, because then the side-by-side COM will not work.

The work around for this bizarre bug is to explicitly in your code (before a.dll or b.dll get loaded as a result of any COM activity) load a.dll:

LoadLibraryW(L"a.dll").

This will also result in b.dll being loaded, but it wont get loaded twice. And now it all works again. b.dll will not get loaded twice and the debugging etc. all works as it did before starting to use the manifest instead of registering the components.
History