Interprozesskommunikation für Windows in C# (.NET 2.0)
https://stackoverflow.com/questions/50153
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich musste IPC noch nie unter Windows ausführen.Derzeit entwickle ich ein Paar Programme, eine Standard-GUI/CLI-App und einen Windows-Dienst.Die App muss dem Dienst mitteilen, was zu tun ist.Unter der Annahme, dass die Kommunikation nur lokal erfolgt, was wäre dann die beste Kommunikationsmethode für diese beiden Prozesse?
Wobei das Beste als robuster und weniger fehleranfällig definiert ist, nicht als das leistungsfähigste oder am einfachsten zu programmierende.
Codebeispiele sind sehr willkommen, aber nicht erforderlich :-)
Hinweis: Ich frage, was ich verwenden soll: einen Standard-TCP-Socket, Named Pipes oder nur ein anderes Kommunikationsmittel.
Danke!
Lösung
IPC in .Net kann erreicht werden mit:
WCF
Verwendung benannter Pipes erfordert .Net 3.0 und darüber.
Codebeispiel
- Die WCF-Klasse NetNamedPipeBinding kann für die Interprozesskommunikation auf derselben Maschine verwendet werden.Die MSDN-Dokumentation für diese Klasse enthält ein Codebeispiel, das dieses Szenario abdeckt http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Fernzugriff
Das ursprüngliche IPC-Framework, das mit .Net 1.0 veröffentlicht wurde.Ich glaube, dass Remoting nicht mehr aktiv weiterentwickelt wird, und wir empfehlen Ihnen, stattdessen WCF zu verwenden
Codebeispiel
Kommunikation zwischen Prozessen über Remoting - verwendet einen TCP-Kanal
Ressourcen
- GenuineChannels verkaufen ein Remoting-Toolkit, das einen Shared Memory Channel enthält. http://www.genuinechannels.com/Index.aspx
- Ingo Rammer, schrieb das endgültige .Net-Remoting-Buch, Erweitertes .NET Remoting, zweite Ausgabe
Win32 RPC mit csharptest-net RpcLibrary
Ich bin kürzlich auf ein Projekt gestoßen, das die Win32-RPC-Bibliothek verpackt und eine .net-Klassenbibliothek erstellt hat, die für lokales und Remote-RPC verwendet werden kann
Projekthomepage: http://csharptest.net/projects/rpclibrary/
MSDN-Referenzen:
- So funktioniert RPC: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
- RPC-Funktionen: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Verfügt außerdem über einen RPC-Client für Google-Protokollpuffer, der auf der Bibliothek ausgeführt wird: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
Der Vollständigkeit halber ist es auch möglich, die WIN32-Methode mit zu verwenden WM_COPYDATA Nachricht.Ich habe diese Methode bereits in .Net 1.1 verwendet, um eine einzelne Instanzanwendung zu erstellen, die mehrere Dateien aus dem Windows Explorer öffnet.
Ressourcen
Steckdosen
Verwendung eines benutzerdefinierten Protokolls (schwieriger)
Andere Tipps
Nur lokal hatten wir mit der Verwendung von Named Pipes Erfolg.Vermeidet den Overhead von TCP und ist (zumindest für .NET) so effizient wie möglich, während es gleichzeitig über eine anständige API verfügt, mit der man arbeiten kann.
Da Sie auf .Net 2.0 beschränkt sind, ist WCF möglicherweise keine Option.Sie könnten .Net-Remoting mit gemeinsam genutztem Speicher als zugrunde liegenden Kommunikationsmechanismus zwischen App-Domänen auf demselben Computer verwenden.Mit diesem Ansatz können Sie Ihre Prozesse problemlos auf verschiedenen Maschinen platzieren und das Shared-Memory-Protokoll durch ein Netzwerkprotokoll ersetzen.
Die Standardmethode zur Kommunikation mit einem Windows-Dienst ist die Verwendung von Dienststeuerungscodes.Windows-Dienste können Codes von 0 bis 255 empfangen.0-127 ist für das System reserviert.128 bis 255 können für benutzerdefinierte Befehle verwendet werden.
Wenn Sie komplexe Objekte an den Dienst senden müssen, verwenden Sie Datenbank, XML, Datei, TCP, http usw.Ansonsten sollten diese Steuercodes zum Senden von Steuerbefehlen wie Neuladen der Konfiguration, Verarbeiten von Elementen usw. verwendet werden.
Es stehen zusätzliche Funktionalitäten wie die Abfrage des Dienstes zur Verfügung.Siehe Windows-Dienstdokumentation und API.
Am besten verwenden Sie WCF.Sie können einen Diensthost im Windows-Dienst erstellen und eine genau definierte Schnittstelle bereitstellen, die die GUI-Anwendung nutzen kann.WCF ermöglicht Ihnen die Kommunikation über Named Pipes, wenn Sie möchten, oder Sie können ein anderes Kommunikationsprotokoll wie TCP, HTTP usw. wählen.Mit WCF erhalten Sie großartige Toolunterstützung und viele verfügbare Informationen.
Ich möchte zu dieser Diskussion beitragen.Bitte tadeln Sie mich, wenn das völlig daneben liegt – aber könnte ein Semaphor (oder mehrere Semaphore) nicht für rudimentäre Kommunikation verwendet werden?
