- Tracing Your Web Application's Activity
- Debugging ASP.NET Applications
- Creating Custom Performance Monitors
- Writing to the Windows Event Log
- Reference
This chapter is from the book
This chapter is from the book
This chapter is from the book
Debugging ASP.NET Applications
The large number of ASP.old programmers migrating their code to ASP.NET ensures that error messages are one of the first things an ASP.NET programmer will typically see. Fortunately, not only is the debugging information provided by ASP.NET much better than ASP.old, but you have much more granular control over how debugging information is displayed in ASP.NET.
An ASP.NET debug page is displayed when an unhandled error is encountered, as long as the appropriate @Page or Web.config settings exist. The output of the page is composed of:
The application (or Web directory) where the error took place
The type of error and a description of the error
Details of the error from the compiler
Source code displaying where the error took place in your code
The file in which the error took place
Links to detailed compiler output and complete source code
Version information for the .NET runtime and ASP.NET
This rich debugging information isn't turned on by default, however. To access rich debugging information, you must turn debugging on, either at the page level (using an attribute of the @Page directive) or for the entire application (using a setting in Web.config).
Enabling Debugging at the Page Level
You can enable debugging at the page level by using an @Page directive.
<@ Page language="C#" debug="True" %>
Don't try testing this by creating an incorrectly coded ASP.NET page and trying to load it on localhost. Errors on the local machine always create debug information. The debug settings control what users on remote machines see. To test debug settings, you'll need to access your error page on a machine other than the Web server machine.
In case you haven't created one of your own already, Listing 3.4 contains an ASP.NET page that contains a bona fide error. You can use this page to test the way ASP.NET generates debug output code.
Listing 3.4 The First Mistake That Most ASP.NET Programmers Generally Make
<% @Page language="C#" debug="false" %>
<HTML>
<HEAD>
<TITLE>ASP.NET Error Page</TITLE>
<SCRIPT runat='server'>
public void Page_Load(Object Sender, EventArgs e)
{
Response.Write "This code will not work."
}
</SCRIPT>
</HEAD>
<BODY>
This is my page. There are many others like it, but this one is mine.
</BODY>
</HTML>
Note that this page has its Debug mode set to false. When you first load it (from a remote machine, remember), you'll get a message indicating that something is wrong with the code on the page. But the output won't display any additional information about the error; in particular, the source code display is suppressed. This is an extremely helpful security feature that ensures that your source code won't be displayed in an error condition unless you specifically permit it through an @Page attribute setting or a debug setting in Web.config.
Enabling Debugging at the Application Level
Turning debugging on and off at the page level is easy enough when you're making changes to only a few pages. But early in the development process, when nothing works, you may want to be able to turn Debug mode on for every page in your application.
You can turn debugging on for all the pages in a given folder by changing a setting in the Web.config file in that folder. You can activate Debug mode at the application level by setting the Debug attribute of the compilation section in Web.config.
Listing 3.5 shows an example of a Web.config file that activates debugging for an entire application.
Listing 3.5 A Web.config File That Activates Debugging at the Application Level
<configuration>
<system.web>
<customErrors mode="Off" />
<compilation defaultLanguage="C#"
debug="true"
numRecompilesBeforeAppRestart="15">
</compilation>
</system.web>
</configuration>
That's it. Remember that when you test this option, it's meaningful only when you're debugging the application from a remote machine. Debug mode is always on when you're logging in to the Web application from localhost.
Using the Debug Object
The .NET framework provides a Debug object that you can use to assist with debugging your application. The Debug object is a member of System.Diagnostics.Debug. An instance of this object is created for you automatically, so you shouldn't ever need to instantiate it yourself. If you used the Debug object in Visual Basic, the .NET framework Debug object should be familiar to you.
Note
A complete reference to the properties and methods of the Debug object appears at the reference section at the end of this chapter.
The Write method is the most common member of Debug you'll use in your day-to-day programming. By using Debug.Write, you can send information to the development environment you run your ASP.NET application in. If you're using Visual Studio, the strings you send to Debug.Write are displayed in the Output window. (You can view them by running your Web application and then selecting View, Other Windows, Output, or by using the keyboard shortcut Ctrl+Alt+O.)
Listing 3.6 shows a typical call to Debug.Write, used to indicate that an ASP.NET page has loaded and its Page_Load event procedure has been entered.
Listing 3.6 Placing a Call to Debug.Write to Display Debug Information in the Development Environment
private void Page_Load(Object Sender , EventArgs e)
{
Debug.Write("Application initializing. Poot.");
}
If you're not using Visual Studio or another integrated development environment to run and debug your ASP.NET application, calls to Debug.Write will go nowhere. A development environment must be present for the output generated by Debug.Write to be meaningful; if you need to send real-time debug information while your application is running, consider using Trace.Write (described earlier in this chapter) or a custom performance monitor (described in the next section).