Ich habe ein TraceSource-Objekt, mit dem ich die Initialisierung einer VB.Net-Anwendung protokollieren kann. Es hat mehrere TraceListeners beigefügt:
Für die ersten beiden möchte ich, dass die Eingabeausgabe "roh" ist - dh ohne die Standardkopfzeile:
%code%
Ich habe einen Wrapper implementiert, der dies tut, wenn TraceEventType auf Verbose:
gesetzt ist %Vor%Ich könnte dies für die gesamte Ablaufverfolgung tun, aber dann würden alle Einträge im EventLog mit Level = Information aufgelistet werden. Ich möchte also den Schweregrad der Trace-Nachricht angeben können, aber ich kann keine Methode auf der TraceSource oder den TraceListeners finden, die mir dies ermöglicht. Soweit ich das beurteilen kann, hat TraceListener diese Optionen zum Schreiben:
Die letzten 3 ermöglichen die Bereitstellung eines TraceEventType (der die EventLog-Einträge korrekt kennzeichnet, aber die resultierende Ausgabe an die Konsole und die Protokolldatei enthält dann die Präfixe und endet wie folgt (zum Beispiel):
%code%
Gibt es eine Möglichkeit, zu überschreiben, wie ConsoleTraceListener und TextWriterTraceListener ihre Ausgabe so formatieren, dass sie diesen Header nicht enthält und gleichzeitig die Einträge mit einem TraceEventType (für das EventLog) kennzeichnen können?
Das ist das Beste, was mir bisher eingefallen ist:
%Vor%Dies scheint zu funktionieren, aber in der Dokumentation zur TraceListener.TraceEvent-Methode von Microsoft , es sagt:
%code%
.. also bin ich mir nicht sicher, ob das gut ist?
Bearbeiten:
Ich habe gerade gemerkt, dass ich, wenn ich so etwas wie mein letztes Beispiel hier mache, die TraceSource überhaupt nicht brauche, da sie ohnehin umgangen wird. Aber es bedeutet auch, dass ich meine eigenen Filter- und Switching-Mechanismen implementieren muss (aber das ist vielleicht ein OK-Preis zu zahlen, um es so zu arbeiten, wie ich es möchte).
Hier ist meine vollständige Lösung dazu, inspiriert von @ Sly die Antwort.
Um die Header-Informationen zu unterdrücken, wenn Sie die %code% -Methode verwenden, können Sie wie folgt von %code% oder %code% (oder welcher Variante des Listeners) übernommen werden;
%Vor%NB. Beim Versuch, die %code% -Methode zu überschreiben, bemerkte ich, dass die Header-Information zu diesem Zeitpunkt noch nicht zur Nachrichtenfolge hinzugefügt wurde. Stattdessen entschied ich mich, den Aufruf zu %code% zum Schweigen zu bringen, der anscheinend keine anderen Auswirkungen hat, aber es fühlt sich ein wenig "hackisch" an, wenn jemand einen "saubereren Ansatz" hat bin offen dafür.
Die Konfiguration zur Verwendung dieses Kunden-Listeners sollte dann etwa so aussehen:
%Vor%Ein anderes ähnliches Projekt, das Listener für die Formatierung enthält, ist Essential Diagnostics , das ursprünglich von Ukadc.Diagnostics inspiriert wurde.
Sie haben jedoch angegeben, dass Sie keine externen Abhängigkeiten wünschen, aber Sie haben immer noch mehrere Optionen, ohne Teile des Frameworks neu zu schreiben:
(A) Anstatt TraceSource neu zu schreiben, ist der entworfene Erweiterungspunkt in .NET Framework, einen eigenen TraceListener zu schreiben.
Wenn Sie eigene Trace-Listener "ConsoleWithoutPrefixListener" und "FileWithoutPrefixListener" schreiben, können Sie die TraceEvent () -Methoden überschreiben, um die Nachricht einfach an TraceWrite () weiterzuleiten (und die Präfixe zu löschen).
Tatsächlich sind weder ConsoleTraceListener noch TextWriterTraceListener versiegelt, daher glaube ich, dass Sie von ihnen erben können und dies mit einer Einzeilenüberschreibung der TraceEvent () -Methode (plus dem Konstruktor) funktioniert.
(B) Eine andere Alternative wäre, EventLogTraceListener für die Quelle konfiguriert zu lassen, aber die anderen zwei Listener unter (statt der Trace-Quelle) zu konfigurieren.
Der Nachteil davon ist, dass Sie in Ihrem Code jedes Mal zweimal anmelden müssen, z. B .:
_traceSource.TraceEvent (_buffer.EventType, ID, _buffer.Text) Trace.TraceWrite (_buffer.Text)
Wenn Sie einige Nachrichten mit Präfixen und einige ohne schreiben möchten, benötigen Sie zwei Ablaufverfolgungsquellen: eine, die mit allen drei Listenern konfiguriert ist, und eine mit nur dem Ereignisprotokoll-Listener.
Schreiben Sie dann in Ihren Wrapper entweder auf die statischen Methoden A (alle drei) oder B + Trace (Quelle).
(C) Persönlich wäre meine Anleitung, Tracing nicht für das Schreiben in das Ereignisprotokoll zu verwenden - wenn Probleme wichtig genug sind, um in das Ereignisprotokoll zu schreiben, möchten Sie normalerweise nicht, dass der Benutzer sie über die Konfiguration ausschalten kann.
>In diesem Fall schreibt Ihr Wrapper direkt in das Ereignisprotokoll (EventLog.WriteEntry oder was auch immer) und dann schreibt Ihr Code in die Trace-Quellen- und / oder Trace-Methoden für die Datei und die Konsole.
Beachten Sie, dass Sie die Berechtigungen berücksichtigen müssen, damit das Schreiben in das Ereignisprotokoll ordnungsgemäß funktioniert. Um eine Ereignisprotokollquelle zu erstellen, muss als Administrator ausgeführt werden . Als Entwickler haben Sie normalerweise Administratorrechte, also müssen Sie dies im Kontext von jemandem, der das nicht tut, richtig testen.
Beachten Sie außerdem, dass nur die Erstgenerierung Administratorberechtigungen benötigt und dies automatisch beim Schreiben der ersten Nachricht erfolgt. Wenn Sie dies also bereits als Entwickleradministrator getan haben, müssen Sie einen sauberen Computer zum Testen finden .
Aus diesem Grund benötigen Sie normalerweise einen EventLogInstaller als Teil Ihres Codes, der von InstallUtil (oder einem gleichwertigen MSI oder was auch immer) ausgeführt wird, der die Ereignisprotokollquelle während der Installation erstellt (weil install von einem Administrator gemacht). Dann, wenn das Programm läuft, existiert die Quelle.
Also, was hat das mit dem Schreiben auf Traces zu tun - nun, wenn Sie nur den EventLogTraceListener in Ihrer Config konfigurieren, dann wird es für normale Benutzer nicht funktionieren; Es wird versucht, Ereignisse in die Quelle zu schreiben (im Attribut initializeData), die dann versuchen, eine Quelle zu erstellen, und wenn sie nicht als Administrator ausgeführt wird, wird sie fehlschlagen.
Wenn Sie ein Installationsprogramm für die Ereignisquelle hinzufügen, haben Sie immer noch ein Problem, wenn jemand die Konfigurationsdatei ändert.
Aus diesem Grund würde ich empfehlen, dass sowohl der EventLogInstaller als auch der EventLog direkt im Code erstellt werden, um sicherzustellen, dass die Namen übereinstimmen, und nicht über die Tracing-Infrastruktur.
Sehen Sie sich das Projekt Ukadc.Diagnostics auf Codeplex an. Es ist ein Addon zu System.Diagnostics, das Ihnen die Möglichkeit gibt, Ihre Logging / Tracing-Ausgabe beliebig zu formatieren (ähnlich wie Sie es mit log4net und NLog tun können). Sie verwenden es über die Konfiguration, sodass Ihr Code keine direkte Abhängigkeit von der Bibliothek aufweist. Die Bibliothek enthält konfigurierbare Objekte zum Formatieren und die benutzerdefinierten TraceListener, die für die Formatierung benötigt werden. Die Bibliothek macht es Ihnen auch leicht, Ihre eigenen Formatierungs "Token" und Ihren eigenen TraceListener zu schreiben.
Sie könnten beispielsweise den Ukadc.Diagnostics ConsoleTraceListener so konfigurieren, dass er eine Formatierungsanweisung in etwa wie folgt verwendet:
%Vor%Jede protokollierte Nachricht würde das Datum / die Uhrzeit, den Namen der Quelle, den Ereignistyp und die Nachricht verursachen.
Probieren Sie es aus, ich denke, dass Sie es mögen werden. Ich habe es selbst benutzt (hauptsächlich für das Prototyping, noch nicht für ein "echtes" Produkt) und hatte guten Erfolg.
Beachten Sie, dass Sie für einige Token (wie DateTime) auch Standardformate anwenden können, die für den Typ geeignet sind (z. B. können Sie für DateTime das Format angeben, in dem Datum und Uhrzeit geschrieben werden sollen).
Der Datei-Trace-Listener, der mit Ukadc.Diagnostics mitgeliefert wird, ermöglicht auch die Angabe seines Dateinamens mithilfe des Tokensystems.