interprozeßkommunikation, strategie

Question

ein bereits vorhandenes programm (vc++, mfc) soll mit einem neuen, noch zu entwickelnden programm (vermutlich c#) kommunizieren.

"kommunizieren" bedeutet dabei: 

- c++ -programm startet c#-exe

- c#-exe hat ein gui (winforms), über das es benutzereingaben entgegen nimmt, ein wenig "schüttelt" und rechnet und "bescheid sagt", daß es ein ergebnis produziert hat

- c++ -programm greift ergebnis (das sind eine handvoll bytes, also keine riesen datenmenge) ab und beendet das c#-programm wieder (bzw. sendet "beende dich")

auf geschwindigkeit kommt es dabei nicht an, eher auf robustheit und einfachheit.

 

darum nun die frage, wie stellt man sowas am schlauesten an. spontan fällt mir entweder eine kommunikation per socket oder per windows-messages ein.

was meint die fachwelt denn dazu? welche strategie sollte unter welchen umständen benutzt werden bzw. nicht. gibt es bessere ansätze, als sockets oder messages?

ps: die kommunikation erfolgt nie über maschinengrenzen hinweg und es gibt von jedem programm auch nur eine instanz

 

gruß und dank

micha

Answer 1

COM-Automation.

PS: Ich frage mich dennoch:
1. Warum Du diese Trennung benötigst.
2. Wäre es evtl. nicht einfacher das C# Assembly in der MFC EXE zu hosten?
3. Warum Du auf C# und Windows Forms aufsteigst?

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 2

> COM-Automation

auch eine möglichkeit, ja. bleibt die fragen:

welche vorteile hätte com gegenüber z. b. sockets?

- einen c#-com-teil einzubinden läuft, soweit ich mich erinner, über das importieren einer tlb-datei und CoCreateInterface. die c#-exe muß als com-server auf dem zielsystem registriert sein, also gesetuped werden, richtig? ein einfaches "da liegt die .exe" reicht nicht aus, oder seh ich das falsch?

- einen socket könnte ich "einfach" per CSocket benutzen, ohne weitere vorrausetzungen, oder?

 

> 1. Warum Du diese Trennung benötigst.

> 3. Warum Du auf C# und Windows Forms aufsteigst?

 das hat eher organisatorische gründe. der c#-entwickler kennt sich in c++ sehr viel weniger aus und will/soll nach möglichkeit nicht in dem "großen" c++-projekt mit rumspielen sondern seine eigene grüne wiese bekommen

 

> 2. Wäre es evtl. nicht einfacher das C# Assembly in der MFC EXE zu hosten?

weiß nicht genau, was du meinst. kannst du mir noch ein stichwort oder info-link zu "c# assembly in mfc-exe hosten" nennen?

 

Answer 3

auch eine möglichkeit, ja. bleibt die fragen:

welche vorteile hätte com gegenüber z. b. sockets?

Du kannst mit Funktionen arbeiten.
Du hast eine prozedurale Schnittstelle.
Timeouts und Beenden der Fremdapplikation besorgt COM für Dich.

Ich würde für so etwas niemals Sockets nehmen. Warum auch?
Eher Sharedmemory, named Pipes.

Ich habe noch nie verstanden, was der Charme an Sockets sein soll, gerade wenn ich mich auf einer Maschine befinde.

- einen c#-com-teil einzubinden läuft, soweit ich mich erinner, über das importieren einer tlb-datei und CoCreateInterface. die c#-exe muß als com-server auf dem zielsystem registriert sein, also gesetuped werden, richtig? ein einfaches "da liegt die .exe" reicht nicht aus, oder seh ich das falsch?

Klar reicht das, wenn die TLB in der EXE ist.
Ansonsten was soll den die EXE einer Kommunikationsschnittsetelle mitteilen, wenn es eben nur binärer Code ist ohne Typensprache?

- einen socket könnte ich "einfach" per CSocket benutzen, ohne weitere vorrausetzungen, oder?

Und? Warum willst Du das? Hat nur Nachteile.
 >   das hat eher organisatorische gründe. der c#-entwickler kennt sich in c++ sehr viel weniger aus und will/soll nach möglichkeit nicht in dem "großen" c++-projekt mit rumspielen sondern seine eigene grüne wiese bekommen

Und! Dann soll er ein Assembly machen, dass den Job macht.
Dazu eine C# Modul, dass dieses Assembly bzgl. UI versorgt und testet.
Das C# Assembly bekommt eine COM Schnittstelle.
Die benutzt Du aus der MFC Anwendnung.
Oder wenn Du es ganz toll machen willst, benutzt die das Assembly direkt mit C++/CLI.

weiß nicht genau, was du meinst. kannst du mir noch ein stichwort oder info-link zu "c# assembly in mfc-exe hosten" nennen?

COM Interop samples und walkthroughs gibt es IMHO einige. Die nutzen zwar of VB als Target, aber COM ist COM, ob aus VB oder VC ist ja wohl egal.
Siehe z.B.
http://msdn.microsoft.com/de-de/library/zsfww439(VS.80).aspx

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 4

> Du kannst mit Funktionen arbeiten.
> Du hast eine prozedurale Schnittstelle.

das sind natürlich klare vorteile, ja.

sehr "charmant" fand ich sockets auch nie, der einzige vorteil, den ich sah, war eben, daß auf dem zielsystem dazu nichts installiert oder ge-regsvr32-t  werden muß.

 

> Klar reicht das, wenn die TLB in der EXE ist.

hm... und du meinst, dann muß nichts mehr registriert werden?

zur build-zeit kommt c++ per #import "...exe" statt per #import "...tlb" an die methoden?

und zur laufzeit reicht es, wenn die exe gefunden wird? kein regsvr32 mehr? dann würde also, ein installiertes .net-framework vorrausgesetzt, "xcopy-deployment" reichen?

 

ich schau mir bei gelegenheit das thema nochmal an, klingt, wenn es denn so einfach geht, tatsächlich besser, als das low-level-socket-bytegeschiebe

Answer 5

sehr "charmant" fand ich sockets auch nie, der einzige vorteil, den ich sah, war eben, daß auf dem zielsystem dazu nichts installiert oder ge-regsvr32-t  werden muß.

Ich verwende in der EXE die solche Komponenten per COm benutzt immer Click-Once Manifeste. Dann brauche ich auch nichts registrieren.

hm... und du meinst, dann muß nichts mehr registriert werden?

Nein!

zur build-zeit kommt c++ per #import "...exe" statt per #import "...tlb" an die methoden?
und zur laufzeit reicht es, wenn die exe gefunden wird? kein regsvr32 mehr? dann würde also, ein installiertes .net-framework vorrausgesetzt, "xcopy-deployment" reichen?

Nein!
Da kannst Du nur mit Click-Once Manifesten vermeiden. Aber das ist ja auch keine Hexerei.

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 6

ich schau mir das bei gelegenheit mal an. danke für die hinweise