Aufrufen einer DLL mit Parametern übergabe

[currywurst]

Hallo zusammen

Gibt es die Möglichkeit aus einem Programm heraus eine DLL oder EXE aufzurufen mit Parametern übergabe und anschliessend aus dieser DLL oder EXE auf eine Antwort zu warten?
Ich muss ein Dienst programmieren der fortlaufend DLL oder EXEs abarbeitet und es logt ob sie erfolgreich oder fehlgeschlagen sind.

Danke für eure Hilfe!

[Christian Marquardt]

In den EXE un DLL wurde vorgesehen, das du Parameter übergibst, und diese werden dann ausgewertet? Grundsätzlich kann man EXE und DLL mit Parametern aufrufen. Jedoch muss das Auswerten der Parameter programmiert worden sein. Für Rückgabewerte gilt das gleiche. http://msdn.microsoft.com/de-de/libr...s.process.aspx -> ExitCode

[gfoidl]

Hallo,

in .net kannst du in jeder Assembly (also EXE und DLL) die public-Methoden aufrufen od. bei EXE, wie von Christian schon erwähnt, Argumente übergeben -> entweder über
[highlight=c#]
static void Main(string[] args)
{
}
[/highlight]
args od. diese über Environment.GetCommandLine ermitteln.

Ich muss ein Dienst programmieren der fortlaufend DLL oder EXEs abarbeitet

Wenn du diese EXEs und DLLs beeinflussen kannst, so wäre es praktisch wenn die abzuarbeitenden Methoden in einer Schnittstelle definiert werden, da sich so der gesamte Ablauf vereinfacht.

mfG Gü

[Ralf Jansen]

Was sind das für Binaries? Z.B. DLLs müssen ja in irgendeinem Prozess gehostet werden denn eine DLL ist ja nicht von sich selbst aus lauffähig. Dürfen die im Prozess des Services laufen? Im Benutzer Context des Services oder in einem anderen(gilt genauso bei den Executables)? Interagieren die vielleicht sonst noch irgendwie mit dem Desktop? Kannst du die DLLs und EXEs für diesen Anwendungsfall anpassen oder sollen das ~beliebige~ Third Party Binaries sein?

Deine Frage kann man im allgemeinen mit ja beantworten im speziellen je nachdem was du da hast könnte aber auch ein nein daraus werden.

[currywurst]

Ja ich habe mir jetzt eine Konsolen Applikation programmiert, die über einen Prozess gestartet wird.
Genau das habe ich gesucht.

            Process myProcess = new Process();
            myProcess.StartInfo.UseShellExecute = false;
            myProcess.StartInfo.FileName = @"C:\Daten\Programmierung\Projekte\Test Projekte\ConAppTestExe\ConAppTestExe\bin\Debug\ConAppTestExe.exe";
            myProcess.StartInfo.Arguments = "test arg2 arg3";
            myProcess.StartInfo.CreateNoWindow = true;
            myProcess.Start();
            myProcess.WaitForExit();

Was momentan noch scheisse ist, dass ich von der Konsolen Applikation kein string zurückgeben kann, nur integer.

Ja es ist so dass ich die EXEs selber programmiere, Zum teil jeodch schon vorhanden sind als DLL, aber diese können umprogrammiert werden.

An gfoidl:
Was bringt mir das genau mit den Schnittstellen?

[Ralf Jansen]

Wenn du selbst eine eindeutige Schnittstelle definierst z.b. (für eine Named Pipes, Tcp oder sonstwie geartete IPC Schnittstelle) die du aufrufen kannst bist du frei in dem was da rein geht und was da wieder rauskommt. Sonst musst du mit dem auskommen was standardmäßig da ist. Und wie du gerade selbst feststellst ist das einzige was standardmäßig bei Executables da ist die Argumente und ein ErrorCode.

[gfoidl]

Hallo,

dass ich von der Konsolen Applikation kein string zurückgeben kann, nur integer.

direkt als Return-Wert geht nur int, aber die Konsolen-Ausgabe (Console.Write/WriteLine) kann mit der Process-Klasse umgeleitet werden und so sind auch Strings möglich.

Was bringt mir das genau mit den Schnittstellen?

Der Dienst wird die EXE und DLLs ja auf eine gewisse Art und Weise verarbeiten od. ist das eher ein Analyse-Tool das die Assemblies scannt?
Bei letzterem bringt die Schnittstelle nicht soviel, aber bei ersterem schon. Z.B. kannst du per Reflection nach der Schnittstelle in der Assembly suchen, genauso wie nach Typen welche diese Schnittstelle implementieren und dann vom Dienst aus einfach über die so gefunden IEnumerable<IMeineSchnittstelle> iterieren und so die Verarbeitung erleichtern.

mfG Gü

[Ralf Jansen]

. Z.B. kannst du per Reflection nach der Schnittstelle in der Assembly suchen,

Die in einen anderen Prozessraum lebt

Vielleicht erklärt uns der OP nochmal genau was hier nötig ist. Darf die zu überwachende Binary im Prozess des Services laufen oder muss es ein eigener Prozess sein.

[gfoidl]

Hallo,

im anderen Prozessraum gehts nicht (zumindest nicht ohne weiteres). Aber es wurde ja noch nicht erwähnt ob die Assemblies ausgeführt werden und darauf zugegriffen werden soll, od. sonst was. Insofern wäre eine Klärung vom OP wirklich gut.

mfG Gü

[currywurst]

Die Assemblies sollen ausgeführt werden in einem anderen Prozess.
Der Service sollte wie folgt funktioniern:
Ein Verzeichnis in dem von unserem PDM-System Job-Datei generiert werden, in der dann die auszuführende Funktion und die Parameter stehen.
Der Service schaut dann in das Verzeichnis und ruft die Job-Datei auf. Liest die Funktion aus und führt dementsprechend die dazugehörige EXE auf und übergibt die Parameter.
Der Service wartet bis die EXE fertig ist(erfolgreich oder nicht) und ruft die nächste Job-Datei auf.

[gfoidl]

Hallo,

das geht dann über die Process-Klasse wie oben schon beschrieben wurde.

Aber was hat das mit den DLLs zu tun?

mfG Gü