Tracing und andere Entwicklerthemen waren in London zur Konferenz SDD (Software Design & Development) Deep Dive angesagt. Taucherausrüstung war nicht von Nöten, stattdessen wurden häufig benutzte und vermeintlich gut bekannte C#-Programmierkonstrukte hinterfragt, auseinandergenommen und wieder zusammengesetzt – so zum Beispiel die Ablaufverfolgung.
Wer wissen will, was seine Anwendung tut bzw. warum die Anwendung im Produktivsystem nicht funktioniert, obwohl sie selbstredend auf dem Entwicklerrechner tadellos lief, kommt um Tracing nicht herum …
System.Diagnostics
Selbstverständlich programmiert man die Ablaufverfolgung nicht jedes Mal neu, sondern verwendet dafür fertige Klassenbibliotheken oder Frameworks. In .NET gibt es hierfür beispielsweise die Klassen aus dem Namensraum System.Diagnostics oder auch das vielbenutzte Framework log4net. Egal, für welche Lösung man sich entscheidet, man sollte in jedem Fall höllisch aufpassen, dass die Ablaufverfolgung nicht in den Programmablauf eingreift und womöglich Ausnahmen und Fehler verursacht, die man ohne Tracing nicht hätte. Was sich aber meistens leider nicht vermeiden lässt, ist ein negativer Einfluss auf die Performance. Üblich ist zum Beispiel das Schreiben von Log-Dateien – und Dateizugriff dauert nun mal seine Zeit. Weiteres Augenmerk sollte man auf die Auswertbarkeit der Log-Dateien richten. Wenn Log-Dateien nicht ausgewertet werden können, kann man sie ebenso gut gleich in den Papierkorb werfen. Da oft nur die Möglichkeit besteht, Zeichenketten auszugeben, sollte man also Wert auf eine geeignete Formatierung legen. Zusammengefasst heißt das, die komplette Last der Ablaufverfolgung liegt bei der Anwendung. Mit der Gefahr, dass sich Anwendung und Ablaufverfolgung gegenseitig in die Quere kommen.
System.Diagnostics.Tracing
Kann man das nicht voneinander trennen? Ja, man kann! Von vielen .NET Entwicklern unbemerkt gibt es seit .NET 4.5 den Namensraum System.Diagnostics.Tracing, der beispielsweise die sehr nützliche Klasse EventSource enthält, die sich hervorragend für die Kommunikation mit ETW eignet. ETW steht für „Event Tracing for Windows“ und ist ein im Windows eingebauter, sehr mächtiger Logging Mechanismus:
- Es können alle im Windows vordefinierten Ereignisse erfasst werden.
- Zusätzlich zum Ereignis selbst können Stack Traces aufgezeichnet werden.
- Der Mechanismus ist erweiterbar, d.h. es können benutzerdefinierte Ereignisse in den ETW Event Stream geschrieben werden.
Nr. 1 und 2 erledigen Tools wie PerfView. Für Nr. 3 kommt oben erwähnte EventSource-Klasse ins Spiel. Alles, was der Entwickler tun muss, ist, diese Klasse abzuleiten und mit den gewünschten Ereignissen, die genau genommen Methoden sind, zu füllen. Im einfachsten Fall könnte dies wie in folgendem C# Codebeispiel aussehen:
{
//Alle gewünschten Ereignisse in Form von Methoden deklarieren.
//In jeder dieser Methoden WriteEvent aus der Basisklasse aufrufen,
//EventID (beginnend bei 1) und alle gewünschten Parameter mitgeben
public void Dateizugriff(string pfad, bool nurLesen) {WriteEvent(1, pfad, nurLesen);}
//Eine Instanz der eigenen EventSource-Klasse bereitstellen
public static MyEventSource Trigger = new MyEventSource();
}
Nun kann man in der Anwendung nach Herzenslust Ereignisse auslösen, und zwar mit folgendem simplen C# Code:
Fertig! Um den Rest kümmert sich oben erwähntes PerfView oder ähnliche Tools. Nun sind Anwendung und Ablaufverfolgung sauber getrennt, und die erfassten Daten sind zudem getypt! Manchmal muss man gar nicht sooo tief tauchen 🙂
In die C#-Welt abtauchen können Sie auch in unseren Seminaren:
Visual Studio 2015 und C# 6.0
Programmieren in C#
Datenzugriff mit ADO.NET Entity Framework
