The problem I'm facing is essentially described here, that is:
- I have a DLL that is using a 3rd party in-process COM component dll.
- I want to use registration free COM with that in-process component.
- I want to embed and use a manfest into this DLL (not into the main EXE) so that I can use the 3rd party component in a reg free way.
- The Interface I use from the component is activated through a call to
CoCreateInstance
. - The 3rd party COM component hasn't got any further (COM) dependencies and doesn't rely on or need isolation.
I see that simply embedding a manifest into my DLL doesn't work, as as is described in the linked question, I will need to switch the Activation Context manually.
What I do not understand is where and when I need to switch the Activation Context: Do I only need to wrap my call to CoCreateInstance
in something like CActCtxActivator ScopedContext
(*), or would I need to wrap all calls into the 3rd party component? (Which, as far as I understand is what ISOLATION_AWARE_ENABLED
is supposed to help with.)
So, when using registration free COM, where do you need to switch the Activation Context?
(*) : Or (**) or whatever.AFX_MANAGE_STATE(AfxGetStaticModuleState());
(**): Actually, AFX_MANAGE_STATE
used to work, but does no longer in "newer" MFC versions. See, e.g. VS2012: Removed support for active contexts switching in MFC?:
We removed all the activation context support from MFC because we .... We use the Windows isolation aware APIs internally in MFC itself.
// posted by: Pat Brenner, Visual C++ Libraries Development: Wednesday, June 05, 2013 11:10 PM
You only need to wrap your call to CoCreateInstance
, given that the 3rd party component has no other dependencies.
If it had other dependencies, then you would need to wrap the calls into the 3rd party component.
来源:https://stackoverflow.com/questions/19299413/where-do-i-need-to-switch-the-activation-context