3

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 AFX_MANAGE_STATE(AfxGetStaticModuleState());(**) or whatever.

(**): 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

Community
  • 1
  • 1
Martin Ba
  • 33,741
  • 27
  • 150
  • 304

1 Answers1

2

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.

Eric Brown
  • 13,308
  • 7
  • 28
  • 67
  • "... then you would need to wrap the calls into the 3rd party ..." - that is to say, those calls that in themselves require the switched Activation Context, i.e. those calls that would trigger (something like) `CoCreateInstance` themselves and where I would want those dependencies be resolved via the switched context? – Martin Ba Oct 10 '13 at 19:07
  • 1
    @MartinBa That's correct. I assumed that you don't always know which calls would need the switched context, and that it's safest to wrap them all. – Eric Brown Oct 10 '13 at 23:19