Track the bug in the ASP.NET code

A tricky problem in Web development is debugging. In ASP or simple JavaScript, developers will use the print statement to track problems in the code. As Microsoft introduces ASP.NET, this approach changes because it contains a lot of features, which can be easier to debug the web page with the TraceContext class. Selecting the scope of tracking in the ASP.NET application, you can launch the ability to track a single page or the entire web application. Web.config This file is used to launch tracking at this level. Here, I use the tracking element in the web.config file: Let us look more carefully Its individual properties: enabled: The level of tracking is used to start (true) and close (pseudo) application. RequestLimit: Used to describe the number of trackers saved in memory. Pageoutput: It is necessary to indicate that the tracking information is required (true) or if (pseudo) is attached to each page. If you choose a pseudo, you can track information in TRACE.AXD in a dedicated tracking page. Tracemode: Used to determine how to display tracking information. In the default, it is set to display in chronological order, but it can also be displayed in the category (sortbycategory) Localonly: It is used to indicate that remote debug can be available (pseudo) or unavailable (true). However, if there is only one page in the application, you will encounter problems when you track. In this case, you can add the following tracking properties in the page command, start the tracking of a single page: <% @ page language = "c #" trace = "true" tracemode = "sortbycategory" codebehind = "WebForm1. aspx.cs "autoeventwireup =" false "inherits =" WebApplication1.webform1 "%> Pay attention to the trace and tracemode properties will conflict with their corresponding properties in the web.config file. If you still don't know which setting is priority, then I tell you that page settings replace Web.config settings, so you have to launch it when you track the entire application, and disable it when you track the selected page. Is it a selection page or an application (or combined with both) to track the tracking to be determined according to the situation. Once the processing output determines the level of the need to track, you will start the result of receiving the tracking. If you are tracking the entire application, you can view all tracking results in the Trace.Axd page (how much is the amount you want to maintain by the requestLimit property). Similarly, after the tracking of a single page, you can view the tracking of a single page. The output result of the tracking is divided into five parts: request details (request details): This part includes the id, request time, encoding, request type (GET, POST, etc.), and status code.

Track Information: Details used to display requests, including all events related to the ASP.NET page. Control Tree: The control used to display the page within the page; this includes its size and the number of related bytes saved in ViewState. Cookie Collection: list of cookies used by the page. Headers Collection: and Request-related HTTP headings, including hosts, cookie, and user-agers. Server variable: and a complete list of request related server environment variables. In the example below, I list some of the information of the tracking results. (Title Set which includes part of the tracking result.) Headers CollectionName ValueConnection Keep-AliveAccept * / * Accept-Encoding gzip, deflateAccept-Language en-usCookie ASP.NET_SessionId = vnadwr45jvrfhv55gbdygobs; LastVisited2 = 3/1/2004 2:11:35 PMHost Localhostuser-agent mozilla / 4.0 (compatible; msie 6.0; Windows NT 5.0; .NET CLR 1.1.4322) From this tracking result, you can see that the requesting client uses English and Internet Explorer 6.0, and installed .NET Framers 1.1 . Joining user information The default tracking capability is useful in many cases, but other cases may require more information on page. You can use the TraceContext class Write (write) and WARN (Warn) method to add user information to the tracking log: Write: Write information to the tracking log. WARN: Write information to the tracking log, but uses red to display information written. Each method is assumed in a variety of tasks, and most basic syntax will accept simple information and insert them into the tracking log. These methods allow you to easily put the TRACE.WRITE and TRACE.WARN statements in the needs of the needs to add user information to the tracking output. Its output is included in the tracking information section of the tracking output. (I think it can be easier to use the WARN method, because they are displayed in red.) Do not need to recompile another very good feature, after completing the tracking, you don't need to delete tracking elements; only If you need to disable tracking, this tracking statement will be ignored. When there is a problem in the product, its advantage is reflected. Once transformation is a product, you can activate the tracking of the application at this level, not to track a single page (set the PageoutPut into false), and view the tracking results through the Trace.axd page, so that users will not be disturbed . Finally, tracking features increase the burden on the application, which will affect the performance of the program. For this reason, you should only start it in the application where you need it, and it is disabled as soon as possible after the trace is completed.