Tracing Overview

Tracing Overview
When you are developing an application, it is often helpful to be able to insert debugging print statements into your code to output variables or structures, assert whether a condition is met, or just generally trace through the execution path of the application. ASP.NET provides two levels of tracing services that make it easy to do just that.
• Page-level Tracing: At the page level, developers can use the TraceContext instrinsic to write custom debugging statements that appear at the end of the client output delivered to the requesting browser. ASP.NET also inserts some helpful statements regarding the start/end of lifecycle methods, like Init, Render, and PreRender, in addition to the inputs and outputs to a page, such as form and QueryString variables or headers, and important statistics about the page's execution (control hierarchy, session state, and application state). Because tracing can be explicitly enabled or disabled for a page, these statements can be left in the production code for a page with no impact to the page's performance. Each statement can be associated with a user-defined category for organizational purposes, and timing information is automatically collected by the ASP.NET runtime. The resulting output can be ordered by either time or category.
• Application-level Tracing: Application-level tracing provides a view of several requests to an application's pages at once. Like page-level tracing, it also displays inputs and outputs to a page, such as form and QueryString variables or headers, as well as some important statistics (control hierarchy, session state, and application state). Application-level tracing is enabled through the ASP.NET configuration system, and accessed as a special mapped URL into that application (Trace.axd). When application tracing is enabled, page-level tracing is automatically enabled for all pages in that application (provided there is no page-level directive to explicitly disable trace).