C# : Methodenaufruf vom Process-Starter aus der als Process gestarteten Anwendung heraus (COM ?)

Gast #2877389
Lesenswert?

Hallo,

ich würde gerne von einem Programm (ConsoleApplication1.exe) aus ein 
anderes Programm (ConsoleApplication2.exe) in Form einer EXE als 
"Process" starten. Das klappt auch soweit. Allerdings würde ich gerne 
von dem gestarteten "Process" aus (ConsoleApplication2.exe) eine Methode 
des Programms (ConsoleApplication1.exe) aufrufen, die den "Process" 
gestartet hat.

Ich könnte mir vorstellen, dass das mit COM machbar wäre. Allerdings 
verstehe ich das nicht ganz, wie ich die Anwendung so registrieren kann, 
so dass ich über COM darauf zugreifen kann. Hat hierfür jemand ein 
einfaches Beispiel? Funktioniert das aus Visual Studio heraus, oder muss 
da vorher immer ein Installer laufen?

Vielen Dank schon jetzt dafür,
Peter

Programm 1:
-----------
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      Process proc = new Process();
      proc.StartInfo.FileName = "ConsoleApplication2.exe";
      proc.Start();
    }

    public void sayHello()
    {
      Console.WriteLine("Hello");
    }
  }
}

Programm 2:
-----------
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication2
{
  class Program
  {
    static void Main(string[] args)
    {
      // Pseudo-Code.
      Reference ConsoleApplication1;
      ConsoleApplication1.Program.sayHello();
      // Pseudo-Code Ende.
    }
  }
}
Gast #2877621
Lesenswert?

Frank Meier schrieb:
> und was ist der sinn des ganzen? ich sehe schon an deinem using
> System.Threading wohin das gehen soll. ich empfehle die
> backgroundworker, die sind sehr einfach zu handhaben.

Hey geil der Typ hat ne Glaskugel!!!

Generell geht das eigentlich ganz einfach mit Pipes unter der 
allgemeinen Bezeichnung Interprocess Communication. DArunter fällt auch 
WCF

Ich denke mit den Schlagworten kannst du wietermachen
#2877647
Lesenswert?

Glaskugel? So eine will ich auch!

Wie wäre es denn damit:

ConsoleApplication1 holt sich beim Anlegen des Prozesses den Eingabe- / 
Ausgabestream (evtl. auch den Error-Stream?). Wenn nun die Methode 
aufgerufen werden soll, schreibt ConsoleApplication2 einfach in den 
Stream, ConsoleApplication1 wertet das aus, führt den Programmcode aus 
und kann ja dann das Ergebnis (Evtl. ist hier Serialisierung für dich 
interessant!?) dann ebenfalls per Stream senden.

Viele Grüße
Der Zahnarzt
Gast #2877669
Lesenswert?

Servus,
ich kann die Klassen HttpListener (Proc1) sowie HttpClient (Proc2) 
empfehlen. WCF ist mir persönlich ein wenig zu komplex. Pipes sind etwas 
"schwieriger".
Sollte der Client beim ersten Connect recht lange brauchen dann hilft es 
den Proxy explizit auf "null" zu setzen - sonst versucht die 
Implementierung selber rauszufinden ob es denn einen Proxy im Netz gibt 
was einfach mal ein paar Sekunden dauern kann.

Ist eine Art Plugin-Architektur nicht auch ein möglicher Ansatz? Dann 
müsstest du nur eine Assembly dynamisch laden, per Reflection die Typen 
suchen die ein vordefiniertes Interface implementieren, Instanziieren 
und die im Interface definierte Start-Methode aufrufen. Das wäre etwas 
weniger komplex bzw. fehleranfällig. Gibt sicherlich auch fertige 
Bibliotheken für sowas...

grüße
Gast #2877753
Lesenswert?

Hallo Peter,

prinzipiell ist der Ansatz eine C# Applikation per COM Interop eine 
andere EXE fernzusteuern ok.
Nur leider liegt das Problem darin, dass in deinem Fall die 
fernzusteuernde Applikation ein "Out-Of Process" Server sein müsste. 
Dieser "Komponententyp" ist unter .Net leider nur sehr eingeschränkt zu 
erstellen und erfordert einigen zusätzlichen Programmieraufwand.
Um in .Net Projekten die Anforderungen für einen "Out-Of Process" Server 
zu erfüllen müssen die benötigten Funktionen nachgerüstet werden.
Eine ausführliche Abhandlung über das Theme ist unter 
http://www.codeproject.com/Articles/12579/Building-COM-Servers-in-NET zu 
finden.
Ich persönlich würde aber empfehlen den Out-of Process Server "native" 
in C++ z.B. unter Zuhilfenahme von z.B. ATL zu erstellen. Hier bieten 
sich viel mehr Eingriffsmgölichkeiten für den Programmierer und das 
Interface kann in der dafür gedachten "Sprache" geschrieben werden (-> 
IDL).

Sollten beide Apps als .Net Projekt erstellt werden, würde ich auf eine 
der vorigen Empfehlungen zur "Prozesskommunikation" zurückgreifen...

Ich hoffe ich konnte helfen.

Viele Grüße
C++
Gast #2877800
Lesenswert?

Hallo,

also das mit HttpListener (Proc1) sowie HttpClient (Proc2) finde ich 
schon mal eine super coole Lösung. Warum bin ich da nicht gleich 
draufgekommen?

Allerdings stellt sich mit die Frage, ob wenn man mit Ports in dieser 
Form arbeitet (Proc1 & Proc2 auf dem gleichen Rechner) irgend eine 
Firewall zicken könnte?

Viele Grüße,
Peter
Gast #2877823
Lesenswert?

Peter schrieb:
> Allerdings stellt sich mit die Frage, ob wenn man mit Ports in dieser
> Form arbeitet (Proc1 & Proc2 auf dem gleichen Rechner) irgend eine
> Firewall zicken könnte?

Ich glaub schon, auch wenn das sicherlich kein typisches setting für 
eine firewall ist lokale kommunikation zu blocken. Aber ich bin da kein 
Experte. Außerdem musst du unter neueren Windosen das "Horchen" auf 
einem Port für einen User erlauben (oder als Admin ausführen).

Das ist aber eben auch genau das Problem an diesem Ansatz. Ich kann nur 
empfehlen einen extra Prozess zu vermeiden wenns auch anders geht. Diese 
2 Anwendungen scheinen ja sehr stark voneinander abhängig zu sein - ist 
die Frage ob die eine ohne die andere überhaupt sinnvoll ist. Wenn nicht 
- dann sollte es auch keine exe sein.
Gast #2877861
Lesenswert?

Wenn die Anwendung wirklich nur auf einem Rechner laufen soll und nicht 
mit einem entfernten intergaieren muss, dann ist diese Lösung nicht 
sinnvoll.

Ich würde so etwas in mehreren Threads ausführen und als zweit 
application, wenn es den überhaupt sein muss, als dll einbinden und 
starten.

hier bizzi was über Threading
http://www.albahari.com/threading/
Gast #2878435
Lesenswert?

@Sebastian L: ...hab das hier gefunden. Funktioniert bis auf die 
Ausnahmebehandlung echt super. Genau das habe ich gesucht. Die 
Stichworte haben es gebracht!

Super Beispiel.

http://fernandozamorajimenez.blogspot.de/2011/10/simple-example-of-using-pipes-with-c.html

@Olek: dll wäre auch gut gewesen, aber in diesem Fall eher nicht 
möglich.

Danke und viele Grüße,
Peter

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren