Benutzer mit den meisten Antworten
Datenaustausch zwischen Programmen

Frage
-
Hallo zusammen,
ich suche nach einer Möglichkeit, zwischen 2 Programmen Daten auszutauschen. Ich habe vor einiger Zeit ein Programm geschrieben, mit dem ich Daten von einer seriellen Schnittstelle abfragen kann. Dieses Programm funktioniert auch sehr gut und ich benutze dieses Programm als Treiber für diese seriellen Geräte, da wir diese oft einsetzen.
Dazu starte ich von meinem "Hauptprogramm" (welches immer Kundenspezifisch ist) die exe des Schnittstellenprogrammes und lege dieses in den Systemtray ab. Das "Hauptprogramm" übergibt die erforderlichen Kommandos an das serielle Endgerät über das Schnittstellenprogramm momentan in Form von Textdateien und bekommt die Antwort auf dem selben Weg in einer zweiten Datei. Da diese Form des Datenaustausches aber ziemlich unsicher ist und durch das Dateihandling der Textdateien ein gewisser Programmieraufwand besteht, suche ich nach einer Möglichkeit die Daten auf dem direkten Weg (z.B. über eine gemeinsam genutzte dll-Datei [oder wie auch immer] )auszutauschen.
Leider verrenne ich mich aber bei jedem meiner Versuche und hoffe, das mir irgendwer einen Denkanstoß in die richtige Richtung geben kann.
Danke schon mal für eure Bemühungen
Antworten
-
Hallo Marko,
letztendlich sind das zwei verschiedene Anforderungen.
Zum einen die Unterstützung unterschiedlicher Waagen bzw. deren Befehlsschnittstellen.
Wenn Du das Vereinheitlichen willst, solltest Du Dir ein allgemeine Schnittstelle (Interface) definieren.
Dieses packst Du in eine Schnittstellen-Bibliothek (.NET Assembly).
Für die Implementation kannst Du jeden Befehlssatz in eine eigene Bibliothek erstellen.
Für das Einbinden kannst Du mittlerweile zwischen unterschiedlichsten Konzepten wählen.
Eine "Auswahl" hatte ich mal gegeben in
Eigene Datentypen aus verschiedenen Assemblies hinter einer Facade-Klasse über ein Interface bekanntmachen
(ein relativ schlanker Weg stellt dort z. B. Unity dar).Der zweite Teil wäre die Kommunkation zwischen den Programmen.
Kommuniziert wird dabei zwischen Prozessen - und nicht zwischen Bibotheken (DLL).
Zur Kommunkation hast Du dabei in .NET wiederum viel Auswahl:
.NET Remoting , was aber heute i. a. durch WCF ersetzt wird.
Oder Du implementierst es selbst über ein API via TCP/IP
zum Beispiel mit TcpClient /TcpListener .
Da Du derzeit dateibasierend arbeitest könnte auch eine Named Pipe in Frage kommen.Ich habe das alles nur kurz angerissen, denn jedes ist Thema für sich,
bei Interesse zum einen oder andere frage nach.Gruß Elmar
- Als Antwort markiert Robert BreitenhoferModerator Donnerstag, 22. April 2010 07:49
Alle Antworten
-
Salut kloppi30
Spannende Frage! Zur Idee via DLL erschliesst sich mir der prinzipielle Unterschied zur TXT-Datei nicht. Wenn Du bei einer Datei bleiben willst, wäre XML sichlich eine bequeme Alternative.
Spontan würden mir als Denkanstösse folgende 2 Möglichkeiten einfallen:
1. Erweiterung des Hauptprogramms
Wenn Du schreibst, dass sich die Hauptprogramme grundsätzlich unterscheiden, die Schnittstelle aber nicht, bietet es sich doch an, die Schnittstelle dem Hauptprogramm hinzuzufügen. Diesfalls könntest Du die Daten bequem im Hauptprogramm abfragen und verarbeiten. Das macht aber nur Sinn, wenn es am Schnittstellenprogramm kaum Änderungen gibt, da Du ansonst stets alle Hauptprogramme patchen müsstest.2. Schnittstelle als Instanz mit öffentlichen Membern
Du schreibst, dass das Hauptprogramm eine Instanz der Schnittstelle erstellt. Dann könntest Du im Prinzip auf die öffentlichen Member der Instanz per Code zugreifen und so die Daten abfragen und Kommandos erteilen. Dieses Szenario wird beispielsweise beim Steueren von Word durch .Net-Anwendungen verwendet. Voraussetzung wäre allerdings, dass Du die Schnittstelle als Reference in Dein Hauptprogramm einbindest. Gemäss http://msdn.microsoft.com/en-us/library/ez524kew(VS.90).aspx ist das Einbinden eines Projektes in ein anderes Projekt als Reference kein Problem. Ob das dann wirkllich läuft und brauchbar ist, müsstest Du ausprobieren. Auch die Frage der Auswirkungen von Änderungen an der Schnittstelle ist noch ungeklärt...Freue mich, zu hören, wie Du das Problem schliesslich gelöst haben wirst.
Gruss Ingo
-
Hallo Ingo,
Danke für erstmal für die schnelle Antwort.
Ich glaube ich werde mein Problem mal spezifizieren. Es handelt sich bei den seriellen Endgeräten um Waagen. In den meisten Fällen benutzen wir die Wägeterminals von einem Hersteller, haben aber auch etliche andere Wägeterminals im Angebot. Für alle dieser Terminals habe ich im Laufe der Zeit diese Schnittstellenprogramme geschreiben und dabei penibel darauf geachtet, das die Befehlsdatensätze zwischen meinem Hauptprogrammen und dem Schnittstellenprogramm immer gleich zu halten. Die Umsetzung des Kommandos in das Format der Waage erfolgt duch das Schnittstellenprogramm. Für die Antworten verfahre ich genauso. Daher ist es uns möglich, bei einem Austausch des Wägeterminals nur die exe des Schnittstellenprogrammes zu tauschen und keine Änderungen am Hauptprogramm zu machen, bzw. mehrere Lizenzen des Hauptprogrammes an verschiedenen Waagen zu betreiben.
Da es für die Wägeterminals mitunter jeweils zig Kommandos gibt und auch aus den vorher genannten Gründen möchte ich die Schnittstelle nicht in meinem Hauptprogramm haben. Daher schwebte mir eine von beiden Programmen gemeinsam genutzte dll vor, die den Datenaustausch zwischen den Programmen realisiert.
Also werde ich mich erstmal auf die 2. gennante Möglichkeit stürzen und mir die Sache mal anschauen.
Gruss Marko
-
Hallo Marko,
letztendlich sind das zwei verschiedene Anforderungen.
Zum einen die Unterstützung unterschiedlicher Waagen bzw. deren Befehlsschnittstellen.
Wenn Du das Vereinheitlichen willst, solltest Du Dir ein allgemeine Schnittstelle (Interface) definieren.
Dieses packst Du in eine Schnittstellen-Bibliothek (.NET Assembly).
Für die Implementation kannst Du jeden Befehlssatz in eine eigene Bibliothek erstellen.
Für das Einbinden kannst Du mittlerweile zwischen unterschiedlichsten Konzepten wählen.
Eine "Auswahl" hatte ich mal gegeben in
Eigene Datentypen aus verschiedenen Assemblies hinter einer Facade-Klasse über ein Interface bekanntmachen
(ein relativ schlanker Weg stellt dort z. B. Unity dar).Der zweite Teil wäre die Kommunkation zwischen den Programmen.
Kommuniziert wird dabei zwischen Prozessen - und nicht zwischen Bibotheken (DLL).
Zur Kommunkation hast Du dabei in .NET wiederum viel Auswahl:
.NET Remoting , was aber heute i. a. durch WCF ersetzt wird.
Oder Du implementierst es selbst über ein API via TCP/IP
zum Beispiel mit TcpClient /TcpListener .
Da Du derzeit dateibasierend arbeitest könnte auch eine Named Pipe in Frage kommen.Ich habe das alles nur kurz angerissen, denn jedes ist Thema für sich,
bei Interesse zum einen oder andere frage nach.Gruß Elmar
- Als Antwort markiert Robert BreitenhoferModerator Donnerstag, 22. April 2010 07:49
-
Hallo Elmar,
danke für diese Denkanstöße. Ich habe mir die aufgezeigten Verweise von Dir mal angesehen und denke, mit dem .Net Remoting bzw WCF bin ich nun auf dem richtigen Weg. Ich werde mir den gesamten Spaß mal antun und ein bisschen rumprobieren. Wenn ich noch Fragen haben sollte, werde ich mich in den nächsten Stunden / Tagen noch mal melden.
Gruss Marko