Hacking ASP.NET: Trace information
All ASP .NET developers propably know about the trace feature in ASP .NET. Provided you have enabled tracing in web.config, (using <trace enabled="true" /> in the system.web element; requesting the url /trace.axd will provide you with a nice list of trace information for the previous requests.
I have often thought about putting the wealth of information to better use; perhaps making more detailed reports based on the trace information. This could be useful during testing. Unfortunately, as far as I can tell, there is no other way to get the information, than requesting Trace.axd. There seems to be no supported programmatic way of doing this.
So I set about finding out, how this could be done. At first I thought about creating a screen-scraper for requesting trace.axd and collecting the information. But this would be impractical; especially when large amounts of data should be collected.
A better approach seemed to be to find out how ASP .NET actually stores this information. Since trace.axd is actually an IHttpHandler (System.Web.TraceHandlers.TraceHttpHandler), the natural starting point was using Reflector to view the internals of this class. It did not take long to figure out, that the HttpRuntime class has a static internal property named Profile of the type System.Web.Util.Profiler, which is internal. This is the class responsible for collecting the Trace information, and has a GetData method. This method returns the current trace information as an IList containing DataSets.
Armed with this information, I wrote a small class that uses reflection to obtain the profiling data. The class looks like this:
1: using System;
2: using System.Collections;
3: using System.Collections.Generic;
4: using System.Data;
5: using System.Linq;
6: using System.Reflection;
7: using System.Web;
9: namespace dr.TraceAnalyzer
12: /// Proof-of-concept class for accessing trace data using reflection.
14: public class TraceData
17: /// Data
19: private IList data = null;
21: /// Gets the trace data in its raw list-of-datasets representation.
23: public IList Data
27: if (data == null)
29: return data;
34: /// Returns the response time for each request stored in the trace data.
36: public IEnumerabledouble>double> RequestResponseTimes
41: var sets = from d in Data.Cast
42: select d;
43: return from set in sets
44: let traceTable = set.Tables["Trace_Trace_Information"]
45: where traceTable != null && traceTable.Rows.Count > 0
46: select (double) traceTable.Rows[traceTable.Rows.Count - 1]["Trace_From_First"];
51: /// Gets the current data from the Profiler instance's GetData method.
54: public IList GetCurrentData()
56: var profiler = GetProfiler();
57: Type profilerType = profiler.GetType();
58: MethodInfo method = profilerType.GetMethod("GetData", BindingFlags.Instance | BindingFlags.NonPublic);
59: return data = (IList) method.Invoke(profiler, null);
63: /// Use reflection to get the Profiler instance.
66: private object GetProfiler()
68: Type runtimeType = typeof (HttpRuntime);
69: PropertyInfo profileProperty = runtimeType.GetProperty("Profile",
70: BindingFlags.NonPublic | BindingFlags.Static);
71: if (profileProperty != null)
73: return profileProperty.GetValue(null, null);
76: throw new ApplicationException("Reflection to get profiler instance failed.");
I have yet to decide what I am going to use the trace data for. But an obvious way to use it would be to represent some of the performance data that is collected, as a graph. For now, I have added a property, RequestResponseTimes, that returns a list of the total time taken for each request stored in the trace data.
And, please remember to disable tracing when putting your site into production ;-)