Developer .NET UPDATE, November 19, 2002

Developer .NET UPDATE—brought to you by the Windows & .NET Magazine Network.
http://www.winnetmag.com


THIS ISSUE SPONSORED BY

Tips & Tricks Web Summit
http://www.winnetmag.com/seminars/tipstricks

SQL Server Magazine
http://www.sqlmag.com/sub.cfm?code=wnei322kdu
(below DEVELOPER .NET PERSPECTIVES)


TIPS & TRICKS WEB SUMMIT
ATTEND OUR FREE TIPS & TRICKS WEB SUMMIT
Join us on December 19th for our Tips & Tricks Web Summit featuring three eye-opening events: "Disaster Recovery Tips & Tricks," "Intrusion Detection: Win2K Security Log Secrets," and "Merging Exchange Systems: Tips for Managing 5 Key Challenges." There is no charge for this event, but space is limited so register today!
http://www.winnetmag.com/seminars/tipstricks


November 19, 2002—In this issue:

1. DEVELOPER .NET PERSPECTIVES

  • Using the web.config File to Trace Web Applications

2. ANNOUNCEMENTS

  • The Microsoft Mobility Tour is Coming Soon to a City Near You!
  • Planning on Getting Certified? Make Sure to Pick Up Our New eBook!

3. NEW AND IMPROVED

  • Print Source Code in Color and Export Output

4. CONTACT US

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

1. DEVELOPER .NET PERSPECTIVES
(contributed by Bill Sheldon, [email protected])

  • USING THE WEB.CONFIG FILE TO TRACE WEB APPLICATIONS

  • Last week, I demonstrated how you can use the Microsoft .NET Framework's Trace object to debug an ASP.NET page. Although using the Trace object to debug a Web page is quite useful, debugging at the page level has some limitations. For example, debugging at the page level doesn't work when you want to maintain the look of the UI or when a display page doesn't exist (as is the case for Web services). In these cases, a better solution is to use the Trace object to debug at the application level by adapting the settings in the application's web.config file.

    Let's revisit the sample project file you created last week so that you can see the difference between how to use the Trace object to debug a Web page and a Web application. In the sample project file's code, remove the Trace="true" property from the top of the .aspx page. From within Visual Studio .NET, open the web.config file for your project and proceed to the trace node. Within this node, you'll see several settings, the first of which is an option called enabled. To turn on tracing for all the pages associated with the sample application, change this option from enabled="false" to enabled="true". At this point, web.config should look like

    <trace
    enabled="true"

    requestLimit="10"
    pageOutput="false"
    traceMode="SortByTime"
    localOnly="true"
    />

    If you were to run this project, you'd notice that the Web application's start page doesn't contain any trace information. This lack of trace information isn't of concern, however, because the web.config file is redirecting the trace information to a different location. By default, the pageOutput property is set to "false", which means that you'll find the trace information at trace.axd. Thus, if your application is typically at http://localhost/cswebapp/webform1.aspx, you would go to http://localhost/cswebapp/trace.axd to view the trace information. If you change the pageOutput property to "true", the trace information appears in the Web application's start page.

    Relocation lets you capture the trace information associated with different users of your application. This capability is quite helpful in debugging. The trace.axd page acts as the index to a series of requests, and the requestLimit property defines the upper limit of the number of requests. This limit is applicationwide, so if you're planning on setting up tracing in a shared environment, you might want to increase the default value. Even if you don't set up tracing in a shared environment, you might want to increase the default value because application tracing uses a static capture. After ASP.NET captures the first set of requests (up to the requestLimit value), the underlying logic doesn't refresh these captured files with future requests. However, you don't want to set the requestLimit value too high because doing so means you're saving each page's trace data. Although this data probably won't cause any short-term problems, a better option is to estimate a reasonable number of requests that will let you complete a test.

    One excellent way to work with application testing is to combine it with an automated testing tool. For example, you can record a script of pages that need to be accessed in Application Center Test (ACT — part of Visual Studio .NET, Enterprise Edition), then rerun your test with one user account. This way, you can examine trace output, make code changes, and rerun the same test so that your results will be easy to locate. As part of the recording session to create your script, you can count the number of pages to get an idea of the number you should use for the requestLimit value.

    The remaining settings are traceMode and localOnly. The traceMode setting controls the display of the trace data within the Trace display. The default value "SortByTime" shows the trace events in the order in which they occurred. Alternatively, you can set the traceMode option to "SortByCategory," which groups events by category. I prefer to see my events in the order in which they occurred so that I can recognize when events are occurring in an unexpected order.

    The default value for the localOnly setting is "true", which means that to see the trace logs, you must access the Web site locally. In other words, you must access the trace.axd page from the local machine. Leaving this default value limits the display of data. However, remote users will see a descriptive error message that tells them that tracing is enabled but that they aren't able to see the trace information because they aren't a local requestor. You wouldn't want intruders to see this message because they might be able to work around the problem and tap into your debugging information. So, this security setting isn't one you should rely on, but I'll save that discussion for a future commentary.

    By adapting the web.config file, you can effectively use tracing to capture all the same data at the application level that you captured at the page level. If you run the same code to write custom tracing events, these events are captured and inserted in the Trace display.

    So far, I've shown you how to use tracing to debug a page and an application. The next step is to use tracing to gain insight into a Web service. I'll show you how to use application tracing in Web services next week. In the meantime, for more information about application tracing, review the documentation.


    SPONSOR: SQL SERVER MAGAZINE

    DID YOU MISS SQL SERVER MAGAZINE'S WEB SEMINARS?
    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
    http://www.sqlmag.com/sub.cfm?code=wnei322kdu


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

  • THE MICROSOFT MOBILITY TOUR IS COMING SOON TO A CITY NEAR YOU!

  • Brought to you by Windows & .NET Magazine, this outstanding seven-city event will help support your growing mobile workforce! Industry guru Paul Thurrott discusses the coolest mobility hardware solutions around, demonstrates how to increase the productivity of your "road warriors" with the unique features of Windows XP and Office XP, and much more. There is no charge for these live events, but space is limited so register today!
    http://www.winnetmag.com/seminars/mobility

  • PLANNING ON GETTING CERTIFIED? MAKE SURE TO PICK UP OUR NEW EBOOK!

  • "The Insider's Guide to IT Certification" eBook is hot off the presses and contains everything you need to know to help you save time and money while preparing for certification exams from Microsoft, Cisco Systems, and CompTIA and have a successful career in IT. Get your copy of the Insider's Guide today!
    http://winnet.bookaisle.com/ebookcover.asp?ebookid=13475

    3. NEW AND IMPROVED
    (contributed by Sue Cooper, [email protected])

  • PRINT SOURCE CODE IN COLOR AND EXPORT OUTPUT

  • StarPrint Limited released VS.NETcodePrint, a Visual Studio .NET add-on that lets you produce customized source-code printouts. The output lets in-house programming staff members reduce training time and enables contract programmers to save clients' maintenance costs. You can preview, print, and export a complete solution, selected projects or their items, namespaces, classes, modules, and procedures. You can export to Rich Text Format (RTF), HTML, and PDF files. The WYSIWYG preview screens provide unlimited zooming, multipage thumbnails, and side-by-side pages. VS.NETcodePrint lets you customize the font attributes and colors. You can apply source code, add line numbers, and use connection lines that show the language statement constructs. VS.NETcodePrint costs $69 and supports Windows XP, Windows 2000, Windows NT, Windows ME, and Windows 9x. Contact StarPrint at +44 (0) 118 979 4107 or [email protected].
    http://www.starprint2000.com

    4. CONTACT US
    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.
    http://www.winnetmag.com/sub.cfm?code=wswi201x1z

    Receive the latest information about the Windows and .NET topics of your choice. Subscribe to our other FREE email newsletters.
    http://www.winnetmag.com/email

    Hide comments

    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.
    Publish