Developer .NET UPDATE, November 12, 2002

Developer .NET UPDATE—brought to you by Windows & .NET Magazine Network.


SQL Server Magazine


No worries! They're still accessible right at your desktop! Kalen Delaney discusses SQL Server internals; Brian Moran identifies performance problems; Rich Rollman teaches about XML for database professionals; Morris Lewis instructs on high availability. Valuable online desktop training at a fraction of the cost of traveling to further your education. Go to

November 12, 2002—In this issue:


  • Tracing Down an Error


  • How Can You Reclaim 30% to 50% of Windows Server Space?
  • Subscribe to Windows & .NET Magazine and Receive an eBook Gift!


  • Automate Conversions to ASP.NET Web Forms

See this section for a list of ways to contact us.

(contributed by Bill Sheldon, [email protected])


  • Last week I discussed how Visual Studio .NET extends your ability to debug applications by letting you step directly into your database. This week, I want to tell you about another debugging feature: tracing. Tracing isn't oriented around the breakpoint but rather involves capturing program values at various points during the execution process so that you can gather information about your application. The Trace object in the Microsoft .NET Framework makes tracing possible.

    Tracing in ASP.NET is an incredibly powerful tool when you're attempting to debug ASP.NET applications. Tracing gives you a simple way to gather information related to the execution of an ASP.NET application without entering the debugger—in other words, tracing lets you perform remote debugging.

    To see the power of tracing in ASP.NET firsthand, open an ASP.NET Web forms project in the language of your choice. Within this project, go to the Web Form Designer window, then select the HTML View. On the first line of the display logic is the page declaration, which starts out something like

    You need to modify this declaration by adding another property to it. After the Language property, add the Trace="true" property. The resulting declaration will look similar to

    At this point, you can run the project. You don't need to add any controls or display information to the page. You also don't need to add any debugging logic to the page code. However, when your sample page displays in the browser, you have a screen full of debugging information related to your application. The default Trace display groups this information into a series of sections, which typically include Request Details, Trace Information, Control Tree, Cookies Collection, Headers Collection, and Server Variables. In addition, the Trace display might include a Querystring Collection or Form Collection section.

    The Request Details section contains the details associated with the HTTP Request object. This information is the same as that embedded in the page request's HTTP header. The Request Details section also specifies the session ID and the type of request (typically Get or Post) used to retrieve the information.

    The Trace Information section's contents are dynamic. By default, this section lists each event that occurs during the handling of the page request. In a page that has no controls and no display, this section is relatively small. The section appears as a table, with four columns: Category, Message, From First(s), and From Last(s). The Category column displays a string describing the category or source of the event (e.g., The Message column displays the messages associated with this trace event (e.g., Begin Render, End Render). The From First(s) value represents a running timer showing the overall time to create the page. The From Last(s) value is also a timer, but this one shows the time since the previous trace event occurred. Thus, as each event starts and ends, the timers indicate where the majority of the work associated with the page occurs. For example, in your sample page, the majority of time is spent between the Begin Render and End Render events, which represents the time needed to render all the trace information.

    The Control Tree section provides information about the size of the various elements in the page. Again the information is in a table, with four headings: Control Id, Type, Render Size Bytes, and Viewstate Size Bytes. The Control Id and Type columns specify the element's name (e.g., __Page) and the element's type (e.g., _ASP.trace1_aspx), respectively. The Render Size Bytes column specifies the number of bytes associated with displaying that element in the browser. Note that this size includes child elements, so the __Page element always indicates the page's total size. The Viewstate Size Bytes column is one you should watch as you begin to add controls to a page. (I'll discuss this column in a future commentary.) In your sample page, the Viewstate Size Bytes value is 20 because the page has no controls that need their state maintained by ASP.NET.

    Cookies Collection is the next section. As the name implies, this section contains the cookies associated with our request, including those that the application is creating as part of the request.

    The Headers Collection section contains the header information that your browser sent to Microsoft IIS as part of the request. This information includes such key elements as the type of browser you're using and, if your server uses Windows authentication, authentication data. However, as I explain in the next section, you can change the authentication mode within ASP.NET so that the default Trace display doesn't include authentication information.

    A QueryString Collection or Form Collection section is only available when you have a page that submits data (e.g., data associated with an HTML form). In the case of most HTML pages, forms are configured to use an HTTP Post call to submit the data from the HTML page. The trace then uses the Form Collection section to display all the data elements submitted with the request. Some forms and many embedded HTTP links use QueryString values. The Querystring Collection section displays these values. Because each request is classified as either a GET or POST request, these sections are mutually exclusive.

    The final Server Variables section is one of the most valuable sections for ASP.NET developers. This section contains the HTTP server values that are defined within the ASP.NET environment and exposed to your application. When you encounter unexpected behavior related to ASP.NET applications, the behavior is often due to not having a key element associated with the server variables.

    If your site requires Windows authentication in IIS, the AUTH_USER value in the Server Variables section contains the Windows NT LAN Manager (NTLM) credentials. However, you can change the authentication mode in the web.config file to either forms authentication or no authentication so that the AUTH_USER value is empty and the Headers Collection doesn't include any authentication information. Although IIS security is separate from ASP.NET security, ASP.NET provides an additional layer of security that you can control separately from IIS. When you implement forms authentication in ASP.NET, you're actually implementing an anonymous Web site in which ASP.NET is responsible for identifying the user.

    Now that you know what kind of information tracing provides, let's look at how you can make calls to the Trace object. Similar to the Session object, the Trace object is part of the HTTP context in an ASP.NET application. Thus, you can reference this object without needing to declare a specific instance of it. In your code, you simply add custom trace statements that enhance the display of information associated with the Web page. The output from the custom trace statements appears in the Trace Information section. For example, open your sample Web page's Web form and add a button to your sample page. Next, double-click this button so that the form's code appears. Add the following code:

    private void Button1_Click(object sender, System.EventArgs e)
       Trace.Write("MyCAT", "Button1 Click");
       Trace.Warn("MyCAT", "Button1 Warning");

    Run your project. On the default page, click the button to trigger the Click Event handler. After the default Trace display refreshes, the Trace Information section will contain two new MyCAT events: Button1 Click followed by Button1 Warning, which appears in red type. Both events include timing information, even though you didn't tell the custom trace statements to specify it. In this way, the custom trace statements provide useful information related to the execution of your project.

    One warning related to using Trace statements on your IIS server: The redistributable version of the .NET Framework doesn't provide support for tracing. The code won't produce an error, but the trace statements simply won't have any effect. That way, if you accidentally leave a trace statement in code that goes to production, that statement won't provide debugging information to your end users.

    Next week, I'll discuss how to edit the web.config file to set up applicationwide tracing values. For now, if you would like additional information on tracing, I recommend the GotDotNet Web site sample.

    (brought to you by Windows & .NET Magazine and its partners)


  • Attend our newest Web seminar, brought to you by Windows & .NET Magazine and Precise SRM, and discover the secrets. Steven Toole will also advise you on how to reduce storage growth and backups by 30% and how to reduce storage administration by 25% or more. Space is limited for this important Web event, so register today!


  • Windows & .NET Magazine is a problem-solving manual designed to help systems administrators better manage their Windows 2000 and Windows NT enterprise. Subscribe today and, with your paid subscription, you can choose from one of three eBooks about Active Directory, public key infrastructure, or automating tasks with VBScript. Subscribe now!

    (contributed by Sue Cooper, [email protected])


  • ArtinSoft released WinFormsToWeb, a tool that lets you automate the conversion of a Microsoft .NET Framework application from Windows forms to ASP.NET Web forms. Windows users enjoy the advantages of a smart-client application, and non-Windows users can still access the same core functionality. Additional features include conversion of ActiveX controls to .NET native controls; full integration with the Visual Studio .NET IDE; delivery of error, warnings, and issue messages of unsupported controls and features; conversion of Windows menus to ASP.NET menus; conversion of binary resources to supported formats on the Web; and an identical navigation structure between Web forms and the original Windows forms. WinFormsToWeb costs $245. Contact ArtinSoft at 425-943-6870, 866-547-4606, or [email protected]m.

    Here's how to reach us with your comments and questions:

    This weekly email newsletter is brought to you by Windows & .NET Magazine, the leading publication for Windows professionals who want to learn more and perform better. Subscribe today.

    Receive the latest information about the Windows and .NET topics of your choice. Subscribe to our other FREE email newsletters.

    Hide comments


    • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

    Plain text

    • No HTML tags allowed.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Lines and paragraphs break automatically.