Console Output innerhalb der Anwendung überwachen

Hallo,

Ich möchte gerne zur Laufzeit überwachen welche Console Messages/Console.WriteLinie innerhalb meiner AppDomain versendet werden.

Ich möchte hierbei nur als externer Beoabachter autftreten.
Die Topics dazu die ich auf msdn gefunden habe, raten mir die Console komplett auf mich umzupipen(redirect innerhalb eines worker threads) was zur Folge hat das die normale Console nicht mehr erreicht wird. Das ist aber nicht was ich will. Die Console soll genauso funktionieren wie bisher. Ich will nur die Standard Console innerhalb meiner Anwendung zur Laufzeit überwachen(mininmal invasiv). Kennt ihr Techniken dazu oder habt ihr Tipps(neue rechtschreibung) für mich? Das ist doch kein neues Problem oder?

wenn du genau das erreichen willst bist du wahrscheinlich mit PostSharp am schnellsten am Ziel. (Wobei ich mir nicht vorstellen kann wozu das gut sein soll.

deine antwort ist sehr allgemein gehalten. bitte spezifiziere deine antwort wie ein komerzielles tool wie post-build mir da helfen kannn.

die antwort ist aber ist aber nur fuer die allgemeinheit da externe kommerzielle tools auscheiden, ich glaube auch nicht das ich die brauche. deine frage warum ich das brauche kennzeichstest du bitte als offtopic. herzlichen dank.

Ich hab mich eine ganze Weile damit auseinander gesetzt, die Konsole für den Entwickler etwas komfortabler zu gestalten.
Problem an der Sache ist, dass der Großteil der Konsole, wie du ihn so kennst, im Windows selber liegt und gar nicht im .NET-Framework.

Also entweder du knüpfst genau da an und findest irgendwie einen WEG, wie du die Windows-API entsprechen nutzen kannst, oder du gehst den Weg über den TextReader und den TextWriter.

Über die Properties In und Out kannst du den jeweiligen Standard erfragen (Bei Out ein Objekt vom Typ SyncTextReader, der nicht öffentlich zugänglich ist).

Du kennst aber auch über die jeweilige SetIn und SetOut-Methode beide setzen, hast dann aber das Problem, dass du dann nicht nur lauschst, sondern die Konsole komplett auf dich umleitest.

Die einzige Idee, die ich hätte, wären folgende:

Du schreibst einen Wrapper für den TextReader (In), der nichts anderes tut, als an den Standard der Konsole durch zu leiten, aber gleichzeitig eben diese Daten an eine andere Stelle abzweigt, wo du sie dann abfragen kannst.

Ob meine Idee so funktioniert, wie ich das schreibe, kann ich dir nicht sagen, das ist nur eine Idee, die ich relativ schnell wieder verworfen habe, weil damit eben nur Abhören möglich wäre und keine komplette Kontrolle der Konsole, was ich ja gesucht habe (Grund ist wieder, dass die Konsole zum Windows gehört).

Du könntest daher hin gehen und eine neue Klasse von TextWriter ableiten, die intern die selben Klassen vom Writer der Konsole aufruft, aber an gleichzeitig abhört.

Wenn ich Zeit finde (Wochenende vielleicht, oder irgendwann zwischendurch), kann ich ja mal ein kleines Projekt daraus machen. Allzu schwierig dürfte das nicht sein. Ich hab es eben mal mit dem TextReader ausprobiert, das funktioniert scheinbar ziemlich problemlos und die Konsole ruft eigentlich nur die entsprechende Methode des Readers auf.
Allerdings kann ich nicht die Methode ReadKey abhören, die wird wohl nicht an den Reader geleitet. Das ist auch der einzige Angreifpunkt für mein Projekt, die einzige Stelle, wo ich direkt sagen kann, dass keine Ausgabe erzeugt werden soll.

Hallo CMajor,

ich würde empfehlen, nicht direkt die Methoden der Klasse Console zu verwenden, sondern eine eigene Klasse für die Konsolenausgabe zu schreiben und zu benutzen. In der eigenen Klasse hast du dann die volle Kontrolle, sofern sichergestellt ist, dass im restlichen Code nicht doch direkt auf die Konsole zugegriffen wird.

Möglicherweise kannst du noch einen Schritt weiter gehen und log4net oder ähnliches verwenden. Dort ist es dann kein Problem mehrere Listener anzugeben, die Ausgaben auf eine Konsole und z.B. in einen Datei schreiben oder was auch immer sonst damit tun.

herbivore

Hallo CMajor,

du könntest TraceListeners verwenden. Dann fügst du den TraceListener einen von TraceListener geerbten Klasse an, welcher dem Programm den Consolen-Output mitteilt.

Ich habe das so gemacht, damit ich die Consolen-Outputs in eine Text Datei abspeichern kann.

Gruß,
Michael

Ich vermute, dass CMajor sich an einen bestehenden Prozess anhängen und lauschen will, was dieser so tut.
Also nichts anderes, was manche "bösen Tools" tun: Eingaben von Anwendungen überwachen und schauen, was dort so ein- und ausgegeben wird.

Ergo wären die genannten Lösungsmöglichkeiten hier nicht zielführend.
Vllt erklärt CMajor nochmal präziser was und wieso er das genau tun will.

Hallo Abt,

Wie ich anfangs schon erwähnte, geht es mir nur um die eigene AppDomain. Es wäre im konkreten Fall sinnvoll den Output von einer Third Party Library zu überwachen und in einem Protokollfenster der Anwendung anzuzeigen. (Fallweise auch einer Crashdump Datei zu speichern)

Der Hinweis von xxMUROxx sieht auf den ersten Blick sehr gut, das probiere ich heute mal und gebe Feedback ob und wie gut das geklappt hat.

Es wäre im konkreten Fall sinnvoll den Output von einer Third Party Library zu überwachen

Wenn diese Library Debug.Write, ..., Trace.Write, ... benutzt so klappt dies mit meinem Vorschlag ohne Probleme.

Hallo CMajor,

die Trace Listeners wirken aber wohl nur auf die Ausgaben, die über die Trace- und Debug-Klassen erfolgen, nicht auf die Ausgaben der Console-Klassen.

Wenn es um eine Third Party Library geht, kannst du dir vermutlich nicht aussuchen, über welche der genannten Klassen die Ausgabe läuft. Vielleicht hast du Glück und es werden die Trace- und Debug-Klassen verwendet. Wenn nicht, wird es mit den Trace Listeners wohl nicht gehen.

herbivore

Hallo herbivore,

Du hast recht. Der Trace Listener arbeitet nicht mit dem Standard Console Output zu zusammen. Ich sehe mein Vorhaben daher als gescheitert an.

Hintergrund ist, wir benutzen eine Library eines externen Anbieters um Zugang zu dessen Datenbank zu erhalten. Diese Library ist leider von schlechter Qualität woran wir nichts ändern können. Es gibt mindestens 5 Gründe warum eine Anfrage zu der Datenbank kein Ergebniss zurückliefert aber die API kanalsiert dies nicht in einer Exception oder einem Result Value sondern liefert immer nur null zurück und gibt den Grund dafür auf der Konsole aus.(analysiert mit ILSpy) Ein unabhängiges überwachen der Konsole wäre zumindest hilfreich gewesen, schade das dies nicht nicht möglich ist ( Ich finde das sollte möglich sein )

Hallo CMajor,

du kannst ja mal deren Support anschreiben. Im Wesentlichen müssen die nur ein global change "Console" durch "Trace" machen und den Consolen-Listener setzen. Dann sollte ihre Bibliothek wie vorher funktionieren, aber ihr hättet die Möglichkeit, einen weiteren Listener zu setzen.

Langfristig würde aber wohl nur eine echte qualitative Verbesserung oder ein Wechsel es Anbieters helfen.

herbivore