2012-11-12 8 views
7

Viele Klassen im .NET-Framework (insbesondere in den Socket-/Netzwerkklassen, die ich mir ansehe) verwenden System.Net.GlobalLog (eine interne Klasse), um Trace-Meldungen irgendwo zu protokollieren. Sie können beispielsweise verwendet Dinge wie GlobalLog.Assert und GlobalLog.Print in der SslState Klasse anzuzeigen:System.Net.GlobalLog - Wie sehe ich die Ausgabe von diesem?

SslStream source code

Dies unterscheidet sich von der System.Net.Logging (auch intern) Klasse, von denen verwendet, kann auch in den Socket/Netzwerkklassen gefunden werden.

Für System.Net.Logging weiß ich, dass ich einen <system.diagnostics> Konfigurationsblock in App.Config verwenden kann, und dies führt dazu, dass System.Net.Logging Nachrichten protokolliert werden, wenn ordnungsgemäß konfiguriert. Dies scheint jedoch System.Net.GlobalLog nicht zu beeinflussen.

Nach etwa einer Stunde Suche kann ich keine Informationen über die Suche nach der Ausgabe von System.Net.GlobalLog finden. Kann jemand die Ausgabe von diesem lokalisieren/sehen/kontrollieren?

Antwort

2

Wie Sie angegeben haben, ist GlobalLog eine interne Klasse für die System.Net-Baugruppe. Ohne die System.Net-Assembly ändern zu können, erhalten Sie keinen Zugriff auf diese Klasse.

Das heißt, Sie können folgende überprüfen möchten: http://www.123aspx.com/rotor/RotorSrc.aspx?rot=42941

Es sieht aus wie Sie Compiler-Flags haben müssen TRAVE und DEBUG Satz, um es zu bekommen .. zu arbeiten, aber ich sehe nicht, wo es macht tatsächlich irgendetwas mit den geloggten Informationen. Die Kommentare legen nahe, dass es nach einer Umgebungsvariableneinstellung suchen und das Protokoll in eine Textdatei irgendwo auf dem System ausgeben soll; Der Code auf dieser Seite scheint jedoch unvollständig zu sein oder wurde einfach nicht beendet.

Meine Vermutung ist, dass Sie eine andere Möglichkeit finden müssen, Zugriff auf die Protokollinformationen zu erhalten, die Sie wollen.

+3

Worauf es hinauslief, war, dass ich, ohne eine Debug/trave-kompilierte Version der System.dll-Bibliothek zu haben, diese Informationen nicht bekommen würde. Außerdem kann der Quellcode dieser Klassen in Visual Studio nicht durchschritten werden, so dass es unmöglich ist, die Vorgänge realitätsnah zu debuggen. Während deine Antwort mein Problem nicht gelöst hat, war es die richtige Antwort. Die ultimative Lösung für mein Problem endete "Graben SslStream und gehen mit BouncyCastle TLS-Implementierung." Ich habe diese Bibliothek bereits für die Zertifikatgenerierung verwendet, so dass dies keine zusätzlichen Abhängigkeiten zu meinem Projekt hinzugefügt hat. –

+0

Darüber hinaus ist System.Net.Logging auch eine interne Klasse und dennoch gibt es eine dokumentierte Möglichkeit, die Ausgabe dieser Klasse anzuzeigen/zu steuern. Nur nicht GlobalLog. Interessant. –

0

Ich habe nicht genug rep, um dies als Kommentar auf die vorhandene Antwort zu setzen, aber ich wollte herausfinden, was in den TcpClient und Socket-Klassen vorging, aber auch gefunden, dass sie nicht betreten werden konnten. Am nächsten kam ich durch Überwachung der Windows-API-Aufrufe, die vorgenommen wurden. Ich habe ein Freeware-Tool namens API-Monitor hier gefunden: http://www.rohitab.com/apimonitor.

Verwandte Themen