Track the bug in the ASP.NET code

xiaoxiao2021-03-06  108

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. Below, you will use the tracking element in the web.config file:

Now let us look at each attribute more carefully:

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 attributes in the page command, start tracking for a single page:

<% @ Page language = "c #" trace = "true" tracemode = "sortbycategory" codebehind = "Webform1.aspx.cs" autoeventwireup = "false" inherits = "WebApplication1.webform1"%>%>

Note TRACE and Tracemode properties conflicts with their attributes corresponding to 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: 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. (Which includes the title set portion 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 the .NET Framework 1.1 is installed.

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's Write (write) and WARN (Warning) methods to add user information to the trace 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 using the WARN method can be easier to find what I added because they are displayed in red.)

No need to recompile another very good feature, after completing the tracking, you don't need to delete tracking elements; just 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.

转载请注明原文地址:https://www.9cbs.com/read-126928.html

New Post(0)