.NET incorporait déja un mécanisme tres puissant afin de pouvoir tracer ( logger, faire des messages de log ) vos applications; Vous pouviez implémenter un log, en utilisant System.Diagnostics et cela via l'objet l'objet Trace, on pouvait écrire des logs; ces messages etaient ensuite relayer par des listeners et suivant ces listeners on pouvait écrire soit vers des fichiers textes, des fichiers XML, l'eventLog de Windows etc ...
On pouvait définir le niveau de trace, par exemple en développement définir un niveau tres haut de maniere à avoir toutes les traces et en production fixer un niveau tres bas afin de ne retenir que les erreurs de l'application.
L'appel a l'instruction permettant de logger etait conditionner par deux directives de compilation DEBUG & TRACE ce qui faisait qu'une partie des instructions de log etait supprimer lors de compilation en mode production.
Malheureusement ces classes du FrameWork 1.0 et 1.1 ne permettaient pas de catégoriser les messages sortant;
Dans mon architecture .net 1.0 & 1.0 j'avais du mettre en place une nouvelle classe appelée TraceManager dont le but etait de catégoriser les messages sortant :
- Information
- Warning.
- Error
- Debug.

J'avais aussi implémenter 3 Listeners :
- XML, EventLog ( plus complet ), SQL dans ces listeners on prenait en compte la possibilité de tracer un objet .net en utilisant la sérialisation et en tracant aussi les informations de la pile ( ligne, application etc ... )

Dans la future version de .net ( .net 2.0, Whidbey 2005 VS.NET ) les mécanismes de traces ont evolués. La catégorisation est maintenant pris en compte en utilisant une énumération TraceEventType, vous pouvez aussi invoquer directement la méthode adéquate mySource.TraceInformation ; le tracages des informations de l'application et de la pile aussi;
Je vous invite à découvrir à partir du blog BCLTeam's WebLog

Il existe des briques permettant de tracer les applications .net ( Log4Net, Logging Block de Microsoft, etc ...