Was macht Intranet-User happy?

Happy-Intranet-Benutzer

Meine Namics Kollegin Vanessa hatte bereits 2014 einen Blogpost als Zusammenfassung eines Workshops beim IOM Summit 2014 in Köln begonnen, letztlich aber nicht fertiggestellt. Ich war selbst nicht dabei, aber es existiert ein Flip-Chart-Foto mit gesammelten Punkten zu der Frage … Weiterlesen

Logging für Windows Store Apps mit WinRT

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.

Im Beispiel oben wurde auf einfache Art und Weise gezeigt, wie das Logging mit WinRT mit den heutigen Mitteln zukunftssicher implementiert werden kann. Sicherlich ist die gebotene Implementierung aus aktueller Sicht noch ausbaufähig, doch bietet sie einen Grundstein für den späteren Einsatz einer mächtigeren Library.