ASP.NET tracing enables you to view diagnostic information about a single request for an ASP.NET page. Tracing also enables you to write debug statements directly in your code without having to remove them from your application when it is deployed to production servers. You can write variables or structures in a page or simply trace through the execution path of your page or application.
In order for tracing information to be gathered and displayed, you must enable tracing for the page or application. When you enable tracing, diagnostic information and custom tracing messages are appended to the output of the page and sent to the requesting browser. Optionally, you can view this information from a separate trace viewer (Trace.axd) that displays trace information for every page in a given application. Tracing information can help you to clarify errors or undesired results as ASP.NET processes a page request.
Trace statements are processed and displayed only when tracing is enabled. You can control whether tracing is displayed to a page, to the trace viewer, or both.
ASP.NET Tracing and Diagnostics Tracing
ASP.NET tracing writes messages that are displayed on ASP.NET Web pages and the ASP.NET Trace viewer (Trace.axd). In contrast, the class is used to trace write messages to the standard .NET Framework trace output (typically a console window). To make it easier to track how your Web forms interact with business objects and other components, you can integrate ASP.NET tracing output with tracing to route all tracing messages to one of these outputs.
Common scenarios that use both ASP.NET tracing and Trace include Web pages that use middle tier business objects to interact with data and business rules, and pages that use enterprise services such as transactions and queues. In these situations the business and enterprise components play key parts in the successful execution of the page, and monitoring their execution flow across the multiple tiers of your application using a single tracing output is desirable.