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 app
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:
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.
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.