mayho33
Goto Top

C-Sharp Commandline Argumente zur Laufzeit entgegen nehmen

Hallo @ All

Ich stehe wieder mal am Schlauch bzw. finde keine entsprechende Lösung und hoffe auf eure Hilfe! Für entsprechende Ansätze/Hinweise wäre ich dankbar!

Was möchte ich tun?

Eine laufende C# WPF Anwendung soll zur Laufzeit Commandline-Argumente entgegen nehmen. Z.B. irgend einen Text und diesen in der View anzeigen

Bisher habe ich nur Beispiele gefunden die zum StartUp Argumente entgegen nehmen. Das ist aber nicht das Problem. Ich brauche etwas das wirklich zur Laufzeit passiert ohne dass die App geschlossen und wieder neu aufgebaut wird.

BSP:

1) MeineApp.exe läuft
2) Nun starte ich ein ConsoleWindow und gebe ein MeineApp.exe DOING="irgend was"
In meineApp.exe wird der Text in einer View (RichTextBox, TExtBlock,...) angezeigt und in die nächste freie Zeile gesprungen. Etwa so wie bei CMTrace.exe (LogFiles lesen während sie geschrieben werden)
3) Schritt 2 lässt sich beliebig oft wiederholen


Vielen Dank für eure Hilfe!

Beste Grüße!

Mayho

Content-Key: 419239

Url: https://administrator.de/contentid/419239

Ausgedruckt am: 29.03.2024 um 08:03 Uhr

Mitglied: 138810
Lösung 138810 18.02.2019 aktualisiert um 18:08:17 Uhr
Goto Top
Da gibt's viele Varianten .z.B.
  • Die von mir favorisierte wäre How to: Use Anonymous Pipes for Local Interprocess Communication
  • Die Anwendung auf einem Socket lauschen lassen und im Load-Event der Anwendung die Parameter prüfen und wenn die Anwendung schon läuft die Daten über das Socket in die Anwendung schreiben lassen und Prozess beenden.
  • Oder die Daten über ein Windows-Message Event in die Anwendung schreiben, dabei die gleiche Prüfung im LoadEvent wie oben, wenn Anwendung schon einen Prozess besitzt, die Daten der Parameter über das Windows-Messaging-System in die Anwendung schieben wobei ein Message-Listener diese entgegen nimmt und ins Textfeld schreibt.
usw.
Mitglied: mayho33
mayho33 19.02.2019 um 11:27:06 Uhr
Goto Top
Hi freesolo,

danke für dein Input!

Wenn ich den Artikel richtig verstehe, werden anonyme Pipes zur Kommunikation vom übergeordneten Prozess zum untergeordneten Prozess verwendet und zurück. Es muss also eine Prozesskette geben. Das gibt es in meinem Fall nicht.

Die oben genannte "MeineApp.exe" ist ein Standallone-Prozess.

Ich veranschauliche etwas deutlicher:

MeineApp.exe überblendet den gesamten Desktop und deaktiviert die Taskleiste. Das wird benötigt um den User daran zu hindern während eines Deployments unternehmenskritischer Applikationen eine dieser Applikationen zu öffnen.
MeineApp.exe ist auf allen Clients deployed und wird als ersten Schritt vom SCCM getriggert. Alle nachfolgenden Deployments die verknüpft sind laufen in einer TS (TaskSequence). Der letzte Schritt ist, MeineApp.exe wieder zu beenden.

Das Deployment läuft während der "LogOn"-Phase. Leider haben wir noch keine Möglichkeit gefunden den LogOn solange zu verzögern bis das Deployment abgeschlossen ist. Deshalb der Workaround mit obigem Beispiel.

Damit der User nicht einfach nur ein FullScreen-Window sieht soll ihm eine Art Echtzeit-Log eingeblendet werden.

Dafür brauche ich einen Art Listener der beim Aufruf von meineApp.exe mit Argumenten nicht einfach die Exe wieder startet sondern die Argumente verarbeitet und anzeigt.

Kann aber auch sein, dass ich komplett verpeilt bin und einfach nicht vestehe was du da schreibst face-wink
Mitglied: 138810
138810 19.02.2019 aktualisiert um 11:41:57 Uhr
Goto Top
Zitat von @mayho33:
Wenn ich den Artikel richtig verstehe, werden anonyme Pipes zur Kommunikation vom übergeordneten Prozess zum untergeordneten Prozess verwendet und zurück. Es muss also eine Prozesskette geben. Das gibt es in meinem Fall nicht.
Dann nehme NamedPipes die haben diese Beschränkung nicht.
https://docs.microsoft.com/de-de/dotnet/standard/io/how-to-use-named-pip ...
Mitglied: rubberman
rubberman 19.02.2019 um 18:12:56 Uhr
Goto Top
Dafür brauche ich einen Art Listener der beim Aufruf von meineApp.exe mit Argumenten nicht einfach die Exe wieder startet sondern die Argumente verarbeitet und anzeigt.

Was sollte denn der Aufruf von meineApp.exe anderes tun, als einen neuen Prozess zu erzeugen? face-wink
Du kannst dein Programm entsprechend anpassen und nur dann das Fullscreen anzeigen, wenn noch keine weiter Instanz läuft. Die Fullscreen Instanz versucht von einer Named Pipe zu lesen. Jede weitere Instanz bleibt ohne Fenster, schreibt auf die Named Pipe und wird anschließend beendet. Mehr würde mir zu dem Thema auch nicht einfallen.

Steffen
Mitglied: mayho33
mayho33 24.02.2019, aktualisiert am 03.03.2019 um 22:45:06 Uhr
Goto Top
Hi Rubberman,

Danke! An einen Mutex-Check dachte ich auch schon. Ich probiere das mal aus und gebe dann Rückmeldung.

Mayho

EDIT:

Danke @138810 ! War doch genau das was ich gebraucht habe und funktioniert super! Hat nur etwas gedauert bis das "eingesickert" ist face-wink

Grüße!

Mayho