5
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
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
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 419239
Url: https://administrator.de/forum/c-sharp-commandline-argumente-zur-laufzeit-entgegen-nehmen-419239.html
Ausgedruckt am: 08.04.2025 um 18:04 Uhr
5 Kommentare
Neuester Kommentar
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.
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
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
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.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.
https://docs.microsoft.com/de-de/dotnet/standard/io/how-to-use-named-pip ...
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?
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
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
Grüße!
Mayho
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
Grüße!
Mayho
