2016-07-18 33 views
0

Ich habe derzeit einen Windows-Dienst und einen separaten GUI-Client, der auf .NET 3.5 abzielt, und versuche, den besten Weg für eine bidirektionale Kommunikation zwischen diesen beiden Prozessen zu finden. Beide Prozesse werden auf demselben Windows-Computer ausgeführt.IPC-Methoden für Windows-Dienst

Die Microsoft Interprocess Communications page scheint zu empfehlen RPC, Pipes oder Sockets für dieses besondere Fall Szenario.

Ich entschied, dass Named Pipes scheinen meine Anforderungen zu erfüllen, aber ich sah mich auch .NET Remoting angetroffen. Es scheint, dass .NET Remoting in WCF als from .NET 3.0 integriert wurde. Von dem, was ich verstehe, WCF verwendet "Named Pipes" zu Kommunikation between processes, so dass ich denke, dass .NET-Remoting und "Named Pipes" irgendwie überlappen.

Kann jemand bitte dies klären? Ich würde gerne verstehen, ob ich Named Pipes, .NET Remoting oder WCF verwenden sollte.

+0

[WCF] (https://msdn.microsoft.com/en-us/library/ms731082 (v = vs.110) aspx) und .NET Remoting sind ähnlich technoliges mit .NET Remoting im Wesentlichen eine ältere Version zu sein von WCF. Named Pipes ist ein Kommunikationsmechanismus und kann von WCF verwendet werden (TCP, HTTP, MSMQ usw.). Was genau meinst du mit bidirektional? – leetibbett

+0

Durch bidirektionale meine ich, dass sowohl Service und der GUI-Prozess sollten in der Lage sein, Daten zu senden und empfangen. –

Antwort

1

WCF ersetzt sowohl .NET Remoting als auch die älteren (jetzt älteren) ASMX-Webdienste. Die WCF NetNamedPipe Bindung Duplex (d.h. unterstützt eine bidirektionale Kommunikation), und da sowohl der Client (der GUI-Anwendung) und der Windows-Dienst auf der gleichen Maschine befinden, named pipes ist ideal.

jedoch zu WCF verwenden Sie den WCF-Dienst zu schreiben, und verwenden Sie den Windows-Dienst es zu hosten, mit der GUI-Anwendung als Client fungiert. Dies ist durchaus möglich, und im Web gibt es viele Beispiele dafür, wie ein WCF-Dienst in einem Windows-Dienst gehostet wird.