Wie kann ich eine prozessexterne COM-Referenz über Prozessgrenzen hinweg bereitstellen?

Question

Ich habe einen Out-of-Process-COM-Server, der die Dinge im Auge behalten muss. Dieser Server wird als Dienst ausgeführt und ist intern ein Singleton. Der Einfachheit halber werde ich ihn BossCom nennen.

Ich habe einen anderen Out-of-Process-COM-Server, der ein Arbeiter ist. Aus Gründen der Systemstabilität handelt es sich um einen Single-Use-Server (das heißt, wenn Sie 2 WorkerCom erstellen, werden 2 WorkerCom.exe ausgeführt). Der Einfachheit halber werde ich ihn WorkerCom nennen.

WorkerCom kann von jedem gestartet werden, auch von selbst, wenn jemand ihn über die Befehlszeile mit den richtigen Befehlszeilenargumenten ausführt.

Das übergeordnete Ziel ist, dass BossCom weiß, welche WorkerComs in der Nähe sind, was sie tun und in der Lage sind, ihnen Befehle zu erteilen (Pause, Stopp, Hochfahren, usw.).

Mein erster Gedanke daran wäre, dass wann immer WorkerCom startet, er CoCreateInstance ein BossCom und BossCom-> RegisterWorker (IUnknown me) aufrufen würde. Wenn dann die WorkerCom kurz vor dem Herunterfahren steht, ruft sie BossCom-> UnregisterWorker (IUnknown me) an. BossCom konnte das IUnknown für IWorkerCom mit QueryInterface abfragen und Befehle ausgeben.

Das würde gut funktionieren, wenn alle diese com-Objekte in demselben Prozess sind, aber sie sind nicht. Ich habe über die Verwendung von GlobalInterfaceTable nachgedacht, aber es ist nur global im Sinne eines einzelnen Prozesses.

Ich habe ein paar Tage damit verbracht, dies zu erforschen und bin ratlos. Vielleicht bin ich Tunnel-Visoned.

Wie kann ich einen Verweis auf ein com-Objekt vom Arbeiter zum Chef marshalieren?

Oh, und was es wert ist, ist BossCom in C# geschrieben und WorkerCom ist in ATL C++ geschrieben, aber ich nehme Lösungen in VB, Scala, Lisp oder irgendetwas geschrieben. Ich denke, ich kann die Kernidee übersetzen. :-)

Answer 1

Laut den Kommentaren funktioniert das tatsächlich out of the box. Es gibt jedoch ein zusätzliches Detail, das es funktioniert.

Ursprünglich, als ich C# -Schnittstellen betrachtete, die sich mit dem Kopieren von Schnittstellen befassten, war der Argumenttyp IntPtr. Nun, ein IntPtr ist nur so lang, dass er den Wert unverändert überträgt und als solcher nicht funktioniert.

Der Schlüssel besteht darin, das MarshalAs-Attribut für das Argument festzulegen. Also meine RegisterWorker-Methode sieht so aus:

public void RegisterWorker(
     [In, MarshalAs(UnmanagedType.IUnknown)] object ptr 
     ) 
    { 
     IWorkerCom worker = (IWorkerCom) ptr; 
     Workers.Add(worker); 
    } 

Absolut erstaunlich.

Answer 2

Ich musste kürzlich etwas Ähnliches machen und fand heraus, dass die Verwendung von Shared Memory sehr gut für mich funktionierte. Der BossCom könnte den gemeinsamen Speicher erstellen und besitzen, und die Arbeiter könnten sich registrieren, indem sie einen Eintrag im gemeinsamen Speicher machen. Hier ist ein MSDN link zu dem, worüber ich spreche. Denken Sie daran, einen Mutex zu verwenden, um den Zugriff auf den Speicher zu synchronisieren ...

Answer 3

Sie sind nur eingeschränkt in der Lage, marshalable Schnittstellen in C# zu erstellen. Keine einfache Möglichkeit, den Proxy einzurichten. Kein solches Problem in ATL, eine Callback-Schnittstelle in der IDL deklarieren. Und übergeben Sie einen Instanzzeiger mit dem Aufruf von RegisterWorker(). Der Server sollte es speichern, bis es den Unregister-Aufruf erhält. Verwenden Sie diese Callback-Schnittstelle, um Benachrichtigungen zu generieren.

Answer 4

Sie sollten einen Blick auf Monikers werfen, die verwendet werden, um eine COM-Objektinstanz auch über verschiedene Maschinen hinweg zu identifizieren.

Answer 5

Sie sollten auch in die ROT (Laufende Objekttabelle) schauen, es könnte eine andere Möglichkeit sein, dieses Problem zu lösen.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms695276(v=vs.85).aspx

http://www.codeproject.com/KB/COM/ROTStuff.aspx