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

[Peter (Gast)]

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.
    }
  }
}

[Frank M. (aktenasche)]

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.

was hindert dich daran, die beiden programme zusammen in ein projekt zu 
packen?

[Peter (Gast)]

Naja,

es sind zwei komplett unterschiedliche Programme, die nichts miteinander 
zu tun haben.

Von der Art ähnlich wie Excel, Word etc. über COM anzusprechen wäre mein 
Ziel.

Viele Grüße
Peter

[Sebastian L. (Gast)]

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

[René Z. (dens)]

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

[Sebastian L. (Gast)]

Ja das ginge simpelster weise auch
WCF und pipes haben aber die nette Eigenschaft events zu feuern auf die 
du reagieren kannst. So musst du nicht ständig deine streams auf 
eingaben prüfen

[r0 (Gast)]

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

[C++ (Gast)]

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++

[Peter (Gast)]

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

[r0 (Gast)]

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.

[Olek (Gast)]

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/

[Peter (Gast)]

@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