Okay, lach nicht. 2005 las ich über die Verfolgung mit System.Diagnostics namespace, es war kompliziert und ich habe seitdem log4net und NLog benutzt (und auch alle anderen).
Heute wird meine App auf Windows Azure-Websites gehostet und verwendet unseren alten Freund Trace .
Smugly, ich habe immer Abstraktionen, IoC, verwendet, also schreibe ich einfach eine neue kleine Shim, um mit Trace zu schreiben, aber es hat nur TraceInformation , TraceWarning und TraceError .
Es gibt einige Write* -Methoden, aber ich habe keine Ahnung, wo sie enden und unter welchen Umständen. Schreckliche API. [Gags]
Welche Methode ist für die ausführliche / Debug-Ebene?
Bearbeiten: entfernt "Easy one" aus dem Titel. Klar ist es nicht.
Was Sie beschreiben, ist die Klasse System.Diagnostics.Trace , die über einige einfache Methoden verfügt, um in die Diagnose-Trace-Ausgabe zu schreiben.
Das ist weit entfernt davon, wie leistungsfähig die Tracing-Diagnose in .NET ist.
Der beste Weg, um die Ablaufverfolgung durchzuführen, ist die Erstellung eines TraceSource . In einer Klasse TraceSource gibt es eine Switch -Eigenschaft, die wiederum eine Level -Eigenschaft hat, in der Sie definieren, welche Ausführlichkeitsstufen für diese spezifische TraceSource gewünscht werden. Sie können diese Tracesource auf alle Ebenen hören lassen:
Um etwas nachzuverfolgen, verfolgen Sie dann die Quelle, in der Sie die Ebene angeben:
%Vor% Die 0 ist die ID der Ablaufverfolgung und dataToBeTraced ist ein Objekt mit den spezifischen Daten, die Sie verfolgen möchten (es ist ein params [] object -Parameter, so dass Sie viele Objekte übergeben können, wenn Sie möchten).
Nun, wie Sie diese Daten verwenden ? Verwenden Sie ein TraceListener , das Sie der Sammlung TraceSource von Listeners hinzufügen. Sie erstellen Ihre eigene Klasse von TraceListener und überschreiben die TraceData -Methode wie folgt:
Der Listener kann unter vielen Spurenquellen geteilt werden und er erhält nur die Datenebene, die er TraceSwitch level zulässt.
System.Diagnostics.Trace verwendet einen Listener wie diesen (der DefaultTraceListener ), die standardmäßig zu Debug.Listeners und Trace.Listeners hinzugefügt wird, aber intern funktioniert es wie ich beschrieben habe.
Das sieht zunächst etwas verwirrend aus, aber es ist wirklich mächtig, und sobald Sie eine Reihe von Hilfsklassen haben ... zumindest habe ich aufgehört, Logging-Bibliotheken von Drittanbietern zu verwenden und diese in großem Umfang zu verwenden.
Was Azure angeht, ist dies eine reine Spekulation, da ich noch nie Azure gemacht habe , aber ich denke, Sie würden Ihre Tracesource in Ihrem app.config (vielleicht web.config ? nicht) konfigurieren sicher über Web), einen Standard-azurblauen Listener für das Protokoll hinzufügen:
"MyTraceSource" ist der String-Name, den Sie im Konstruktor angegeben haben, wenn Sie dies über den Code tun.
Oder Sie können einfach einen TraceSource im Code wie oben erstellen und einen TraceSource zu seiner Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener Sammlung hinzufügen
Ich wollte meine eigene Geschichte hinzufügen.
Die einfache Antwort auf meine Frage ist, dass Trace.WriteLine effektiv ausführlich ist. Die .NET-Ablaufverfolgung ist zwar leistungsfähig, aber kompliziert, aber es ist mir gelungen, sie in den Tabellenspeicher zu integrieren.
Aktivieren Sie im Azure-Portal die Anwendungsprotokollierung (Tabellenspeicher) auf der Registerkarte Konfigurieren und richten Sie Ihre Tabelle ein. Wenn Sie eine neue erstellen, wird diese erst angezeigt, wenn Sie Änderungen speichern.
In Ihrer Anwendung müssen Sie nur Methoden für System.Diagnostics.Trace verwenden und WAWS wird den erforderlichen Listener automatisch einrichten.
Mein Stolperstein hat fatale Nachrichten angemessen verfolgt. Da es für kritische Nachrichten keine statische Methode gibt, bin ich gezwungen, die Methoden auf TraceSource zu verwenden und meine gewünschte Level-Enumeration einzugeben.
Zum Beispiel kommt in meiner Logging-Abstraktion der Level als LoggingLevel.Fatal und ich muss TraceSource.TraceEvent(TraceEventType.Critical, ...
Aber nur ein TraceSource neu zu erstellen, macht nichts, da Jcl erklärt, dass es einen Listener braucht. Das ist, wo ich jetzt feststecke.
Dies benötigte einen Verweis auf Microsoft.WindowsAzure.Diagnostics im SDK lokal, aber es kompiliert seltsamerweise nicht.
Diese Besetzung wird nicht funktionieren. Ich sollte es sowieso nicht brauchen.
Fehler 3 Kann den Typ nicht konvertieren 'Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener' zu 'System.Diagnostics.TraceListener' Evoq.AppName.CoreLib C: \ DATA \ Code \ AppName \ Evoq.AppName \ Evoq.AppName.CoreLib \ Instrumentation \ AzureApplicationDiagnosticsLogger.cs 30 28
Seltsam ist, dass der RedGate Reflector eine solche Vererbungskette zeigt:
%Vor% Wenn ich meine TraceSource -Klasse dort wiedergebe, dann (auch) von:
Seltsam. Ich gebe jetzt auf. Ich habe ein Produkt zu versenden. Ich wende mich wieder der statischen Trace -Klasse zu und kehre zu ihr zurück, wenn sie zu kosten beginnt.
Lukas
Tags und Links .net c# tracing instrumentation