Tracking bugs in the ASP.net code

A tricky issue with asp.net web development is debugging. In the era of ASP or simple JavaScript, developers use Print statements to track problems in their code. This approach has changed as Microsoft introduced ASP.net, because it contains a lot of features that make it easier to debug Web pages with TraceContext classes.

Select a range of tracking

In a asp.net application, you can initiate the ability to track a single page or an entire Web application. Web.config this file is used to initiate tracing at the application level. The following elements are used in the Web.config file:

<trace enabled= "false" requestlimit= "ten" pageoutput= "false"
Tracemode= "SortByTime" localonly= "true"/>

Now let's take a closer look at the various properties:

Enabled: Used to start (true) and close (pseudo) applications at this level of tracing.
Requestlimit: Used to describe the number of traces kept in memory.
Pageoutput: Used to indicate whether tracking information needs (true) or not (pseudo) appended to each page. If Pseudo is selected, the tracking information can be viewed in a dedicated tracking page--trace.axd.
TraceMode: Used to determine how tracing information is displayed. In the default state, it is set to display in chronological order, but it can also be displayed by category (SortByCategory).
Localonly: Used to indicate that remote debugging is available (pseudo) or unavailable (true).
However, if there is only one page in the application, you will encounter problems while tracking. In this case, you can start tracking a single page by adding the following trace attribute to the page's command:

<%@ Page language= "C #" trace= "true" tracemode= "SortByCategory"
Codebehind= "WebForm1.aspx.cs" autoeventwireup= "false"
inherits= "Webapplication1.webform1"%>

Be aware that the trace and TraceMode properties conflict with their corresponding properties in the Web.config file. If you're not sure which setting is the priority, then I'll tell you that the page setup replaces the Web.config setting, so you start it when you're tracking the entire application and disable it when you track the selected page. Whether to select a page or an application at the level (or to combine the two) for tracking depends on the situation.

Processing output
Once you've decided which level to track, you're about to start receiving the results of your tracking. If you are tracking the entire application, you can view all the tracking results on the Trace.axd page (depending on how many you maintain with the requestlimit attribute). Similarly, after tracking a single page, you can view the tracking of a single page.

The output of the trace is divided into five parts:

Request Details: This section includes the ID of the session, the request time, the encoding, the request type (get, post, and so on), and the status code.
Trace information: Used to display the details of the request, which includes various events related to the ASP.net page.
Control tree: Used to display controls that are used within a page, including their size and the number of related bytes saved in viewstate.
Cookie set (Cookies Collection): A list of cookies used by the page.
Title set (Headers Collection): HTTP headers associated with the request, including host, Cookie, and User agent (User-agent).
Server variables: A complete list of server environment variables associated with the request.

In the following example, I have listed some information about the tracking results. (It includes a section of the title set that tracks results.) ）

Headers Collection
Name Value
Connection keep-alive
Accept */*
Accept-encoding gzip, deflate
Accept-language en-US
Cookie Asp.net_sessionid=vnadwr45jvrfhv55gbdygobs; lastvisited2=3/1/2004
2:11:35 PM
Host localhost
User-agent mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;. NET CLR
1.1.4322)

As can be seen from this tracking result, the requesting client uses English and Internet Explorer 6.0 and is installed. NET Framework 1.1.

Add user Information
The default tracking capability is useful in many situations, but other situations may require more information about the page. You can use the write (write) and warn (warning) methods of the TraceContext class to add user information to the tracking log:

Write: Writes information to the trace log.
Warn: Writes information to the trace log, but displays the written information in red.
Each method takes on a variety of tasks, and most basic syntax accepts simple information and inserts it into the tracking log. These methods allow you to easily place Trace.Write and Trace.Warn statements where you need them, thereby adding user information to the trace output. Its output is included in the Tracking information section of the trace output. (I think using the Warn method makes it easier to find what I've added because they're shown in red.) ）

No recompilation required
Another very good feature is that after tracking, you don't need to delete trace elements, just disable tracing, so that trace statements are ignored. When there is a problem in the product, its advantages are reflected. Once transformed into a product, you can activate tracing at the application level instead of tracking individual pages (pageoutput), and Trace.axd pages to view the tracking results so that the user is not disturbed.

Finally, the tracking feature increases the burden on the application, which in turn affects the performance of the program. For this reason, you should only launch it in the production application when you need it, and disable it as soon as possible (after tracing is complete).

--------------------------------------------------------------------------------
The author of this article: Tony Patton's career began with application developers and has been certified by Java, VB, Lotus, and XML to increase its expertise.