How to do registration-free COM in a plug-in architecture

Question

We use manifest files to do registration-free COM, as I've also elaborated on in this other question.

Now we're trying to use registration-free COM with an application that supports plug-ins. The plug-ins are OCX files that can be added to the main application's folder after the main application is already installed.

However, that means that the manifest file of the main application would need to be patched by the plug-in installer. That seems like a dangerous and error-prone thing to do, especially if multiple plug-ins can be installed.

Is there a way to somehow split the manifest file of the main application, so that each plug-in can safely add it's own part as a separate file? Or another safe way to patch the manifest file?

In case it is relevant: we create our installers with wix.

Teliospore

Answer 1

I wouldn't recommend modifying the manifest file of the application; that seems fairly fragile and would only work if it lives in a writeable location.

At process startup, an application's manifest is used to generate an "activation-context" which is pushed as the process-wide activation context. But each thread also has an activation-context stack, which can be directly manipulated. Operations on a given thread look both at the topmost context on the stack and the process-wide activation context when looking for COM registration data.

The recommendation is that any time plugin code needs to call into COM, a plugin-specific manifest should be activated on the thread. This can most easily be done in one of two ways:

1. Embed the plugin-specific manifest as an ID2 manifest into the plugin and compile with the macro ISOLATION_AWARE_ENABLED defined. This basically wraps common Windows APIs that need context from a manifest to automatically activate and deactivate the proper activation context around the call.

2. Activate/Deactivate the proper activation context on the thread around all the entry points into the plugin. This is done through the activation context APIs. This is most easily done with an activation context management object.

Unfruitful

Thank you, Eugene. Do you know of any sample code that uses at least one of these solutions? Thank you. – Revegetate

I actually got this to work by following the guide here: mazecomputer.com/sxs/help/sxsapi3.htm And also example code from vvvsample here: msf.codeplex.com but I have to copy the COM dll to the same directory as the exe which is what I'm trying to avoid. I'm currently passing the full path of the external manifest and the full path of the test directory to CActCtxHandle.Create() (ex. "C:\Rel\MyCppTests.dll.manifest" and "C:\Rel" respectively). The COM dll also resides in "C:\Rel" but the exe resides in a different directory (ex. "C:\TestRunner"). Any ideas? – Revegetate

Approach 2 can be found here: https://mcmap.net/q/1316529/-nunit-test-with-fortran-dll – Typesetter

Answer 2

If you're using .Net, you can use the code shown in this answer to take care of the activation contexts.

Difficile