Story of trace.AXD

Hoffentlich kennt jeder das sehr nützliche Tracing Feature in ASP.NET. Tracing erlaubt es während der Laufzeit von Code mitzulesen ohne dabei den Benutzer zu beinträchtigen. Dieser Artikel blickt ein wenig hinter die Kulissen und erlaubt es das Konzept für eigene Zwecke einzusetzen.

Das Tracing wird per Konfiguration in der Web.Config aktiviert.

<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />

Alle Informationen werden dann auf einen Trace Stack geschrieben. Um auf diesen Stack zuzugreifen bietet ASP.NET die Datei trace.axd.
Wer sich auf die Suche nach diesem File begibt wird dies aber vergeblich tun. Des Rätsels Lösung verbirgt sich in der machine.config. Diese beinhaltet zentral alle Settings, ähnlich wie die Registry allerdings im Klartext und als XML Daten.

Aufrufe von Browsern auf die Trace.axd werden dann per HTTPHandler and die Klasse Tracehandler umgeleitet.
Andere direkte Aufrufe von z.B. Source Code Dateien wie mit der Extension .VB oder CS werden an den HTTPforbiddenHandler geleitet, der vermutlich ne schöne 404 Meldung oder was ähnliches erzeugt.
Es lässt sich auch per remove ein Handler wieder entfernen. Auch in der Web.Config ist dies möglich um so für ein bestimmtes Web Tracing zu deaktivieren.
Die TraceHandler Klasse wird im Namespace System.Web.Handler gehalten, der leider nicht dokumentiert ist. Dies vor allem, damit niemand auf die Idee kommt diese direkt zu verwenden. Schliesslich könnte Microsoft diese Klasse in der nächsten Version komplett ändern.
Eine der wenigen Hinweise in der Doku besagen nur das dieser Namensraum in XP Home, 98 und SE nicht vorhanden ist. Das mag wohl auch einer der Gründe dafür sein, das ASP.NET auf diesen Betriebssystemen nicht läuft.
Der IL Code findet sich in der Datei System.Web.DLL. Also kann man dieser auch mit dem Tool ILDASM zu Leibe rücken.

Hier kann man durchaus etwas über die Funtkionen und deren Weise (Funktionsweise) erfahren. Ob es Sinn macht, sei dahingestellt.
Im Vergleich mit der Version 1.2 des .NET Frameworks (preview alpha von 2.0) kann man erkennen, das die Funktionen beinhae identisch sind.Im der nächsten Version wird davon auch rege Gebrauch gemacht. So werden weitere Handler über die AXD Extension eingeführt.

<httpHandlers> <add verb="*" path="trace.axd" type="System.Web.Handlers.TraceHandler" /> <add verb="GET" path="WebAdmin.axd" type="System.Web.Handlers.WebAdminHandler"/> <add verb="GET" path="WebResource.axd" type="System.Web.Handlers.AssemblyResourceLoader" /> <add verb="GET" path="CachedImageService.axd" type="System.Web.UI.Imaging.CachedImageServiceHandler" /> <add verb="GET" path="counters.axd" type="System.Web.Handlers.SiteCountersHandler" /> <add verb="GET" path="precompile.axd" type="System.Web.Handlers.PrecompHandler" /> ....

Da sind ein paar ganz interessante Ideen dabei wie, Image Caching oder Webverwaltung.
Dies aber im näheren Detail wenn die Beta von .NET 2.0 erscheint.
Allerdings ist die Idee dahinter auch für andere Dinge verwendbar. Mein erster Gedanke war unsere Web Analyzer Programm Visendo so auszustatten. Damit können alle Webs die gleiche Klasse verwenden um grafisch die Logfiles auszuwerten. Allerdings muss dann natürlich die DLL im global Assembly Cache abgelegt werden.
Dafür erspart man sich jede weitere Konfiguaration für Subwebs.