Topic: out of process the COM-server without registration in the register
There was a task of operation with indirect Cs ++ libraries which support the assembly only under 32 bits, from 64-bit application. Decided to use 32-bit out of process COM the server, that not interprocess calls. . Complexity that application-client should work without installation (from a flash card, dvd, etc.) . Isolated COM and Side-by-Side manifestos allow regstration free only for DLL in-process, therefore such variant disappears. Some circuit with two exe as a result appeared. The big request to criticize, since experience in development of COM-servers was not. COM only from client side all road used... So in a directory two lie exe-shnika: the 32-bit COM-server (ATL) and the 64-bit client software program. In the register is registered nothing. The client launches the COM-server through CreateProcess, remembers process id. We wait while the server registers classes, before an input in a cycle of messages the server signals named event (its client and waits). The server guid a COM class somewhere in ole32.dll, but without record in the register to the client object not to create... We Cause CoGetClassObject which searches for a meta-class in the registration table ole, we receive IClassFactory and we create our COM object. It is enough to create one "root" object (with a name root, application, service manager...) And it already to use a surrounding for all operation and, in particular, as factory for other necessary objects (different classes). In the client we use generation of stubs through #import... no_dual_interface. Accordingly stubs work through IDispatch:: Invoke. It removes a problem with , arising that we typelib is not registered in the register. There is one problem. Registration of COM classes in ole32 - global, is not present a warranty that the class registered that process of the COM-server, which client launched through CreateProcess. If the user launched some copies of the program from one or different directories each copy should use the process of the COM-server. In general, any similarity Side-By-Side is necessary. It has been decided to register objects class factory in running object table (IRunningObjectTable) with a unique moniker for each process. A moniker to make from guid a class and id server process. The client also knows guid a class and id server process, can construct an appropriate moniker and through IRunningObjectTable:: GetObject to receive class factory. At usage ATL on server side there was some complexity with capture of a local copy class factory since after construction it is transferred in CoRegisterClassObject and more links to it in process does not remain. Function FinalContruct at ATL-evskoj bases for COM objects Here helped, in it registration class object in running object table transits successfully to call CoRegisterClassObject. I will be grateful for any councils and remarks.