Ich habe diese Woche versucht, mit Named Pipes auf dem neuesten Stand zu sein. Die Aufgabe, die ich mit ihnen zu lösen versuche, ist, dass ich über einen vorhandenen Windows-Dienst verfüge, der als Gerätetreiber fungiert und Daten von einem externen Gerät in eine Datenbank überträgt. Jetzt muss ich diesen Dienst ändern und ein optionales Benutzer-Front-End hinzufügen (auf demselben Computer mit einer Form von IPC), das die Daten überwachen kann, die zwischen dem Gerät und der Datenbank übertragen werden, sowie einige Befehle an den Dienst zurücksenden kann .

Meine ersten Ideen für den IPC waren entweder Named Pipes oder Memory-Mapped-Dateien. Bisher habe ich die Named-Pipe-Idee mit @ durchgearbeiteWCF Tutorial Grundlegende Interprozesskommunikation. Meine Idee ist, den Windows-Dienst mit einem zusätzlichen Thread einzurichten, der den WCF-NamedPipe-Dienst implementiert, und diesen als Kanal für die Interna meines Treibers zu verwenden.

Ich habe den Beispielcode funktioniert, aber ich kann mich nicht um 2 Probleme kümmern, von denen ich hoffe, dass mir hier jemand helfen kann:

Im Tutorial wird der ServiceHost mit einem Typ von (StringReverser) instanziiert, anstatt auf eine konkrete Klasse zu verweisen. Daher scheint es keinen Mechanismus für den Server zu geben, der mit dem Dienst selbst interagiert (zwischen den Zeilen host.Open () und host.Close ()). Ist es möglich, eine Verknüpfung zwischen dem Server und der Klasse, die den Dienst tatsächlich implementiert, herzustellen und Informationen zwischen ihm weiterzuleiten? Wenn das so ist, wie

Wenn ich eine einzelne Instanz des Servers und dann mehrere Instanzen der Clients ausführe, erhält anscheinend jeder Client eine separate Instanz der Serviceklasse. Ich habe versucht, der Klasse, die den Dienst implementiert, einige Statusinformationen hinzuzufügen. Diese wurden nur in der Instanz der Named Pipe beibehalten. Dies hängt möglicherweise mit der ersten Frage zusammen, aber gibt es trotzdem eine Möglichkeit, die Named Pipes zu zwingen, dieselbe Instanz der Klasse zu verwenden, die den Service implementiert?

Schließlich irgendwelche Gedanken über MMF vs Named Pipes?

Edit - Über die Lösung

Als Antwort von Tomasr liegt die Lösung darin, den richtigen Konstruktor zu verwenden, um eine konkrete Singleton-Klasse bereitzustellen, die den Service implementiert ServiceHost-Konstruktor (Object, Uri [])). Was ich damals nicht zu schätzen wusste, war sein Hinweis darauf, dass die Serviceklasse threadsicher ist. Das bloße Ändern des Konstruktors verursachte einen Absturz des Servers und führte mich letztendlich auf den Weg, InstanceContextMode aus diesem Blogeintrag heraus zu versteheInstancecontextmode und Concurrencymode. Das Einstellen des richtigen Kontexts rundete die Lösung ab.