Need shared property accross instances of my COM server

Question

I have a VB.NET COM class with a Shared property, like ABC. The problem is the component is used by several C++ COM exe, so its my understanding that they each will get their own assembly load, and the Shared property will be unique to each EXE. Is there a way to get for this assembly a cross EXE shared property ?

Tx.

Answer 1

What you are describing would be "easily" accomplished in native COM by creating an out-of-process COM server (also commonly referred to as an ActiveX EXE). As the name implies, an out-of-process COM server runs in its own process and serves it's methods via a COM interface. If multiple clients use the COM server simultaneously, they both share the same server process, so any global data within that process is shared between all of the clients.

Unfortunately, .NET does not provide any mechanism for creating an out-of-process COM server. All COM visible .NET assemblies act as in-process COM libraries, so each client using it has it's own set of global data within their own processes.

The only alternative is to create a standard in-process COM-visible library, but have it just be a pass-through wrapper which calls out to some other process. Inter-process communication in .NET is typically handled with WCF, so the typical solution would be to have a WCF service running in the back-end with which the COM-visible library communicates. If you don't want to use WCF, you could also look at .NET Remoting or raw TCP/IP sockets.

Here's a chicken-scratch diagram to help visualize what I mean:

Answer 2

Create a Windows Service application and either register your shared singleton object in ROT or simply use RegisterActiveObject/RevokeActiveObject to register it with a unique guid.

Accordingly, use ROT or GetActiveObject to obtain a COM proxy to this object from any other place. You'd need to manually start the windows service if the object has not been registered.

Updated, it's also possible to implement IClassFactory on the singleton object (which would return itself). The service would register the singleton via CoRegisterClassObject, resembling the out-of-proc server behavior. The initial service activation would still be required.

Finally, perhaps the simplest solution is to register the assembly as an out-of-proc DLL surrogate. I haven't tried that, but it ought to be easy with [ComRegisterFunction] / [ComUnregisterFunction] custom interop registration.

Updated, here is an example of using a surrogate process.