2

we are trying to change and in-proc COM object to an out-of-proc COM object. The new process just passes an Dispatch to previously used COM Object, so we can optionally go back to an in-proc object. This is working fine, but we encounter problems concerning the events. The out-of-process server intercepts the events of the previously used COM object and passes these to an own event interface which is also working. But the problem is that the client cannot connect to this event interface using DispEventAdvise when the out-of-process server is not registered in the windows registry.

The server IDL looks like:

[
  object,
  uuid(www),
  dual,
  oleautomation,
  nonextensible,
  helpstring("IControl Interface"),
  pointer_default(unique)
]
interface IControl : IDispatch
{
  [id(1)] HRESULT CreateDispatch([out] IDispatch** ppDispatch);
};

[
  uuid(xxx),
  version(1.0),
  helpstring("Control Type Library")
]
library ControlLib
{
  importlib("stdole2.tlb");
  [
    uuid(yyy),
    helpstring("IControlEvents Interface"),
    nonextensible
  ]
  interface IControlEvents : IUnknown
  {
    [id(1)] HRESULT MyEvent(void);
  };

  [
    uuid(zzz),
    helpstring("_IControlEvents Interface")
  ]
  dispinterface _IControlEvents
  {
    interface IControlEvents;
  };

  coclass Control
  {
    [default] interface IControl;
    [default, source] dispinterface _IControlEvents;
  };
};

We added the control_i.c, control_p.c and dlldata.c to client and server. And both perform the follwing steps to register the proxy/stub.

PrxDllGetClassObject(IID_IControl, IID_IUnknown, (void **)&punk);
CoRegisterClassObject(IID_IControl, punk, CLSCTX_INPROC_SERVER, REGCLS_SINGLEUSE, &dwRCO);
CoRegisterPSClsid(IID_IControl, IID_IControl);
CoRegisterPSClsid(IID_IControlEvents, IID_IControl);
CoRegisterPSClsid(DIID__IControlEvents, IID_IControl);

This is working for the Control to be created using CoCreateInstance, but not for the events. DispEventAdvise keeps returning CONNECT_E_CANNOTCONNECT cause the QueryInterface for DIID__IControlEvents on the sink returns E_NOINTERFACE.

We really need to get this working without registering the control inside the registry. We also tried to get it registered using manifest files and also separate proxy/stub DLLs but had no success.


bazz-dee
  • 687
  • 5
  • 23
  • I don't think the problem is in unavailability of PS for event interface (what you are trying to fix with `CoRegisterPSClsid` call). The problem is that the hosting type library needs to be available, and then stock proxy/stub implementation would be applied over it. You need to make type information/library available through reg-free COM: manifest, activation context etc. – Roman R. Mar 20 '15 at 10:34
  • Keep in mind that your last snippet won't be used when you use a manifest. I'd speculate that the server fails since it doesn't know what proxy/stub to use. Include the manifest in the server as well and try again. – Hans Passant Mar 20 '15 at 12:51
  • @RomanR.: We already tried to add the type library to the manifest but also without any success. – bazz-dee Mar 23 '15 at 11:27
  • @HansPassant: Well even with manifest, it makes a difference with or without the last snippet. – bazz-dee Mar 23 '15 at 11:27

1 Answers1

1

We ended up registering only the dispatch event interface in the registry, to have the stub class registered correctly. It is now "registered" but without any file references. So we still can have side-by-side installations.

bazz-dee
  • 687
  • 5
  • 23