Instead of enabling tracing for individual pages, you can enable it for your entire application. In that case, every page in your application displays trace information. Application tracing is useful when you are developing an application because you can easily enable it and disable it without editing individual pages. When your application is complete, you can turn off tracing for all pages at once.
When you enable tracing for an application, ASP.NET collects trace information for each request to the application, up to the maximum number of requests you specify. The default number of requests is 10. You can view trace information with the trace viewer.
By default, when the trace viewer reaches its request limit, the application stops storing trace requests. However, you can configure application-level tracing to always store the most recent tracing data, discarding the oldest data when the maximum number of requests is reached. For more information.
To enable tracing for an application:
1.Open your Web site's Web.config file. If no Web.config file exists, create a new file in the root folder and copy the following into it:
<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<system.web>
</system.web>
</configuration>
2.Add a trace element as a child of the system.web element.
3.In the trace element, set the enabled attribute to true.
4.If you want trace information to appear at the end of the page that it is associated with, set the trace element's pageOutput attribute to true. If you want tracing information to be displayed only in the trace viewer, set the pageOutput attribute to false.
For example, the following application trace configuration collects trace information for up to 40 requests and allows browsers on computers other than the server of origin to display the trace viewer. Trace information is not displayed in individual pages.
<configuration>
<system.web>
<trace enabled="true" pageOutput="false" requestLimit="40" localOnly="false"/>
</system.web>
</configuration>
When you enable tracing for an application, ASP.NET collects trace information for each request to the application, up to the maximum number of requests you specify. The default number of requests is 10. You can view trace information with the trace viewer.
By default, when the trace viewer reaches its request limit, the application stops storing trace requests. However, you can configure application-level tracing to always store the most recent tracing data, discarding the oldest data when the maximum number of requests is reached. For more information.
To enable tracing for an application:
1.Open your Web site's Web.config file. If no Web.config file exists, create a new file in the root folder and copy the following into it:
<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<system.web>
</system.web>
</configuration>
2.Add a trace element as a child of the system.web element.
3.In the trace element, set the enabled attribute to true.
4.If you want trace information to appear at the end of the page that it is associated with, set the trace element's pageOutput attribute to true. If you want tracing information to be displayed only in the trace viewer, set the pageOutput attribute to false.
For example, the following application trace configuration collects trace information for up to 40 requests and allows browsers on computers other than the server of origin to display the trace viewer. Trace information is not displayed in individual pages.
<configuration>
<system.web>
<trace enabled="true" pageOutput="false" requestLimit="40" localOnly="false"/>
</system.web>
</configuration>
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.
Enabling Tracing
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 Trace 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 System.Diagnostics 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.
Enabling Tracing
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 Trace 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 System.Diagnostics 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.
Visual Debugger allows you to examine code while it is running and includes features that help you debug applications, including the following:
To enable debugging for an ASP.NET Web application, you must configure the application to compile into a debug build. A debug build includes information that the debugger needs so that it can step through your code and display the contents of variables. You configure your Web application for debug builds in the Compilation section of your application's Web.config file or debug=true to the @ Page directive on the pages that you wish to debug.
Local and Remote Debugging
If you are running a Web server locally, such as IIS, you can debug applications running locally on your computer so that you can view your pages in a browser.
If you cannot run a page locally, because you cannot run a Web server or because the application is not available to you locally, you can debug an application running on another server. In order to debug remotely, you must install the Visual Studio remote debugging components on the remote server.
Permissions for Debugging
Debugging a process requires more privileges than running it. Therefore, in addition to configuring your application for debugging, you must also ensure that you have adequate permissions to attach to a process in order to debug it. Users have the permission to debug processes running under their own user local identity, but they cannot debug other user's processes. Administrators can debug any process.
To debug on a remote server, you need administrator privileges on the computer where the process to be debugged runs. For more information, see How to: Debug Web Applications on a Remote Server.
Client-Side Script Debugging
In addition to server-side application debugging, Visual Debugger allows you to debug client script written in ECMAScript (JavaScript) or VBScript. Client-script debugging can be especially useful when you have Web server controls that use client-side script.
- Breakpoints Breakpoints are places in the code where the debugger will stop the application, allow you to view the current data state of the application, and then step through each line of code. For information.
- Stepping Once you have stopped at a breakpoint, you can run the code line by line (known as stepping through the code). Visual Debugger includes a number of features to help you step through your code, such as iterators that allow you to specify how many times to step through a loop before stopping again.
- Data Viewing Visual Debugger gives you many different options for viewing and tracking data while the application is running. The debugger allows you to modify the data while the application is stopped in break mode and then continue to run the application with the modified data.
To enable debugging for an ASP.NET Web application, you must configure the application to compile into a debug build. A debug build includes information that the debugger needs so that it can step through your code and display the contents of variables. You configure your Web application for debug builds in the Compilation section of your application's Web.config file or debug=true to the @ Page directive on the pages that you wish to debug.
Local and Remote Debugging
If you are running a Web server locally, such as IIS, you can debug applications running locally on your computer so that you can view your pages in a browser.
If you cannot run a page locally, because you cannot run a Web server or because the application is not available to you locally, you can debug an application running on another server. In order to debug remotely, you must install the Visual Studio remote debugging components on the remote server.
Permissions for Debugging
Debugging a process requires more privileges than running it. Therefore, in addition to configuring your application for debugging, you must also ensure that you have adequate permissions to attach to a process in order to debug it. Users have the permission to debug processes running under their own user local identity, but they cannot debug other user's processes. Administrators can debug any process.
To debug on a remote server, you need administrator privileges on the computer where the process to be debugged runs. For more information, see How to: Debug Web Applications on a Remote Server.
Client-Side Script Debugging
In addition to server-side application debugging, Visual Debugger allows you to debug client script written in ECMAScript (JavaScript) or VBScript. Client-script debugging can be especially useful when you have Web server controls that use client-side script.
Application code can contain various types of errors, or bugs. Most syntax errors are caught during compilation. However, other types of errors require that you debug your code — that is, that you examine the code while it is running to validate that the execution path and data is as it should be.
The topics in this section provide information about how to use the debugger in the Windows Software Development Kit (SDK) to help you find errors in ASP.NET Web pages.
ASP.NET includes features to help you diagnose problems that might arise in your Web application. These include:
The topics in this section provide information about how to use the debugger in the Windows Software Development Kit (SDK) to help you find errors in ASP.NET Web pages.
ASP.NET includes features to help you diagnose problems that might arise in your Web application. These include:
- A debugger that you can use to step through a page or component as it is running.
- Techniques for avoiding errors and capturing information when they do occur.
- Ways to trace page requests and gather information about each step of page processing.
- Ways to raise and respond to health monitoring events, which can log information about performance and error conditions.
There are number of important settings that can be stored in the configuration file. Here are some of the most frequently used configurations, stored conveniently inside Web.config file..
- Database connections
- Session States
- Error Handling
- Security