Logging ist in der Programm-Entwicklung eine der wesentlichsten Methoden zur Fehlerverfolgung. So nimmt die Bedeutung von Logging mit den neuen .NET 4.5 Features (speziell async/await) zu, da im asynchronen Programmcontext bei unsachgemässer Implementation nicht deterministische Fehler “geschluckt” werden können. Die Nachverfolgung solcher Fehler gestaltet sich, ohne Protokollierung, als äusserst schwierig.
Was WinRT bietet
Als rudimentäres Logging-Feature hat Microsoft zu diesem Zweck in WinRT die Event Tracing for Windows (ETW) Library für das Mobile- und Desktop-App Framework integriert. Dieses entfaltet vor allem für kleinere Entwicklungen seine Stärken, ist allerdings für den Einsatz von grösseren und komplexeren Lösungen nur bedingt geeignet. Es fehlen markante Features wie das Uploaden der Log-Files auf einen zentralen Server. Zusätzlich enthält das von Microsoft gebotene Beispiel Multithreading-Probleme, welche beim Save des Log-Files zum Tragen kommen können.
MetroLog kann Abhilfe schaffen
Das MetroLog Framework als OpenSource Projekt nimmt sich dieser Problematik an. Dieses basiert auf NLog und bietet neben der klassischen Logging-API auch den besagten Upload zum Server an. Weiterhin bietet MetroLog die Features zum Loggen von Daten ins ETW oder in eine lokale SQL-Lite Datenbank. Ein Beispiel zu MetroLog findet sich unter: https://github.com/mbrit/MetroLog/blob/master/Samples/ConsoleSample/Program.cs
Wunsch-Framework: log4net und noch mehr…
Persönliche habe ich eine Vorliebe für das log4net Framework. Dieses wurde bereits bei diversen .NET Projekten eingesetzt und ist entsprechend in der .NET Community etabliert. Ebenfalls setzen bereits bestehende interne Basis-Funktionalitäten log4net ein. Diese Funktionalitäten sollen nach und nach zu WinRT migriert werden, ohne hierbei ein grosses Rewrite zu generieren.
Leider exisitiert im Moment noch keine Implementierung des log4net Frameworks für WinRT. Aus diesem Grunde heisst die Lösung im Moment: Facade-Pattern der GoF. Mit Hilfe dieses Patterns, kann die effektive Logging-Implementierung im Nachhinein ohne Probleme ausgetauscht und so beispielsweise durch log4net Komponenten ersetzt werden.
Die Anwendung der Facade (Klasse Logger<T>) sieht wie folgt aus:
Durch die Facade kann ebenfalls die Logging-API minimiert werden. Im Beispiel werden direkt die Logger<ExampleClass>-Methoden aufgerufen. Diese loggen anschliessend die Mitteilung im Namen der Klasse ExampleClass. Der Compiler sorgt implizit dafür, dass genau eine Instanz des Templates Logger<ExampleClass> existiert, daher muss der Logger nicht explizit in jeder Anwender-Klasse instanziiert werden. Dank der Verwendung des Compiler-Features müssen auch keine Performance-Einbussen hingenommen werden.
Die Implementation der Logger<T> sieht im Prinzip sehr einfach aus:
Fazit
WinRT bietet im Moment erst rudimentäre Logging-Funktionalitäten. Dafür stehen Frameworks wie MetroLog zur Verfügung. Wer sich allerdings an ein zukunftssicheres API binden möchte, ist gut beraten, eine eigene Entwicklung anzustreben.