Regardless of the method you use to build an application, the application is compiled in debug mode by default. This is bad. Building an application in debug mode can have a severe impact on performance.

Before you release an application into production, you’ll need to modify two configuration settings. First, select Release from the Solution Configurations drop-down list (see Figure 6.1). After you select Release, make sure that you build your application one more time.

Figure 6.1. Building an application in release mode.

Second, you’ll need to modify your application’s Web.Config file. Open the Web.Config file from Solution Explorer. Find the <compilation> section and assign the value false to the debug attribute.

When developing an application, you normally need to develop the application in debug mode. If you don’t develop the application in debug mode, you cannot view runtime errors and you cannot use the integrated Visual Studio .NET debugger.

When you build an application in debug mode, the /debug and /optimize compiler options are sent to the C# or VB.NET compiler. The /debug option causes the compiler to generate a programmer database (.pdb) file. Without a .pdb file, Visual Studio .NET cannot display runtime errors. The .pdb file contains a mapping between MSIL code and source code.

The /optimize compiler option tells the compiler to perform automatic optimizations on your code. However, because the compiler may optimize your code by rearranging it, enabling optimization can prevent debugging from working.

A Web Form Page consists of two files—the presentation page and the code-behind file. The two parts of a Web Form Page are compiled in different ways.

The code-behind file must be explicitly compiled. When you compile a project in Visual Studio .NET, you are compiling the code-behind files in the project. All the code-behind files are compiled into a single assembly (.dll file) that has the same name as your project. This assembly is placed in the /bin folder of your application.

You can view this assembly in a project by selecting Show All Files from the Project menu and expanding the Bin folder in the Solution Explorer window. When a project is compiled in Debug mode, this folder will contain a .dll file and a .pdb file. When a project is compiled in release mode, it will contain only the .dll file.

The presentation part of your Web Form Pages—the .aspx files—also must be compiled. However, you are not responsible for compiling the presentation pages. The ASP.NET Framework handles the compilation of these pages for you in a process known as dynamic compilation.

The ASP.NET Framework automatically compiles any .aspx page when the page is first requested. The compiled assembly that corresponds to the requested page is stored in the following folder:

WINNTMicrosoft.NETFrameworkFramework Version Temporary ASP .NET FilesProject Name

If you look in this folder, you’ll find folders and files with strange names like 1e994b and 892323.dll. The .dll files correspond to the compiled presentation pages. If you are really curious, you can open these files with ILDasm, the Intermediate Language Dissassembler, and view their contents.

When the presentation pages in an application are compiled in debug mode (in other words, <compilation debug=true /> in the Web.Config file), a bunch of additional files are added to the folder. For example, you should see files with the extensions .cmdline, .cs, and .vb. The .cmdline files contain the actual statement that was sent to the compiler to dynamically compile a presentation page. The .cs and .vb files contain the source code for the presentation page class file.

There are four types of errors that might prevent a Web Form Page from executing:

There are two configuration settings that determine how errors are displayed. First, you need to enable debugging for both the code-behind files and the presentation pages in your application to view detailed runtime error information. Unless debugging is enabled, .pdb files are not generated and the source of the error cannot be displayed (both of these options are enabled by default).

Second, by default, errors are not displayed on a remote computer for security reasons. If you are developing an application on a remote Web server, you’ll need to disable custom errors to see error messages. Open the Web.Config file from the Solution Explorer window, find the <customErrors> tag and assign the value Off to the mode attribute. Disabling custom errors will cause errors to be displayed on a remote computer. For this reason, you need to be careful to re-enable custom errors when you are ready to deploy your Web application.

After you have made these configuration changes, you can view error information in two places. When you compile the code-behind pages in a project, you can view any compilation errors by opening the Task List window (Select Show Tasks from the View menu and open Build Errors). All other errors will appear in the Web Form Page itself when it is displayed in a browser.

Before you can debug an application, you need to set one or more breakpoints. A breakpoint is a point in your code where you want the execution of your application to temporarily stop. After you stop your application at a breakpoint, you can step through your code and view the values of variables.

You set a breakpoint by clicking on the left margin of the Code Editor. A breakpoint is represented with a filled red circle (see Figure 6.2).

Figure 6.2. Adding a breakpoint.

After you add a breakpoint, start your application by selecting Start from the Debug menu (you’ll need to specify the Startup Page and Startup Project in the Solution Explorer window). The Web Form Page that was selected as the start page will stop executing when the breakpoint is hit.

After your code has hit a breakpoint, you can step through your code line-by-line by using the commands from the Debug toolbar. From the Debug toolbar, the Debug menu, or by using special keys, you can:

The Step Into and Step Over commands require additional explanation. The only difference between Step Over and Step Out is when the next statement to be executed is a method, function, or subroutine. If you use Step Into, the debugger steps into the function, executes the first statement in the function, and then stops execution. If you use Step Over, the debugger executes the entire function and stops execution at the next line.

You can also control execution by dragging the yellow arrow that appears at the margin of the Code Editor. For example, if you drag the yellow arrow down, the intervening code will be skipped.

There are a number of windows that appear when you are using the debugger. You can use these windows to monitor the current state of your application when your application is running. Not all of these windows appear automatically, but you can open any of them by selecting Windows from the Debug menu.

A watch enables you to see the current state of a variable. The Visual Studio .NET debugger supports two types of watches—Watches and QuickWatches.

You can open up to four Watch windows from the Debug, Windows menu. After you open a Watch window, you can add as many variables to the window as you want. There are several ways that you can add an individual variable to the Watch window:

As you step through your code, the values of variables in the Watch windows are automatically updated (see Figure 6.3). You can even modify the values of variables directly in the Watch window. Modifying the values of variables modifies their values in the executing code.

Figure 6.3. Adding a watch.

The second type of watch is a QuickWatch. You can open a QuickWatch window by selecting QuickWatch from the Debug menu or by right-clicking in the Code Editor and selecting QuickWatch. If you select a variable in the Code Editor before opening the QuickWatch window, the variable and its current value will automatically appear in the QuickWatch window.

You can use the QuickWatch window for more than just viewing the values of variables. You can also use the window to evaluate expressions and get the return values of methods and functions. After you enter an expression, click Recalculate to see the expression’s value (see Figure 6.4).

Figure 6.4. Using a QuickWatch.

All errors in the .NET Framework are represented by exceptions (instances of the Exception class or a derived class). For example, a division by zero error is represented by the DivideByZeroException class.

You can configure the debugger so that when an exception is thrown in your application, the application will automatically switch back to the debugger in the same way as if it hit a breakpoint. That way, you can examine the values of all the variables at the point when the exception was hit. You can even decide to continue the execution of the application after the exception.

You configure how the debugger handles exceptions by selecting Exceptions from the Debug menu. The Exception dialog box enables you to specify responses to two different conditions. First, you can indicate that your code should break into the debugger as soon as there is an exception. You also can indicate that your code should switch to the debugger when an exception is not handled by your code.

These options enable you to handle two different scenarios. You might want to debug an exception even when it is being handled by your code in a Try...Catch block. Alternatively, you might want to break to the debugger only in the case of unhandled exceptions.

Unfortunately, these options can be confusing in the case of Web Form Pages. All exceptions in a Web Form Page are automatically handled by the ASP.NET Framework. Therefore, the only meaningful option when debugging a Web Form Page is to select the option to break into the debugger when the exception is thrown.

You can select this option by selecting Common Language Runtime Exceptions and selecting Break Into the Debugger in the When the Exception Is Thrown panel. After you select this option, a red ball with an X should appear next to Common Language Runtime Exceptions (see Figure 6.5).

Figure 6.5. Handling exceptions in the debugger.

You can use the debugger to debug client-side script in your Web Form Pages. The debugger can be used with both VBScript and JavaScript client-side code.

The first step in enabling client-side script debugging is to enable debugging in Internet Explorer:

Unfortunately, you can’t set breakpoints in the same way for client-side script as you can for normal server-side code. Instead of setting a breakpoint in the Code Editor, you need to use either the debugger statement (in the case of JavaScript) or the Stop statement (in the case of VBScript).

For example, the following client-side JavaScript script will break into the debugger when the debugger statement is hit:

function window_onload() {
  var someVar = 23;
  debugger;
  document.write( someVar );
}

When debugging VBScript scripts, you need to use the Stop statement:

Sub window_onload
  Dim someVar

  someVar = 23
  Stop
  Document.write(someVar)
End Sub

When the debugger or Stop statement is reached, the Web Form Page will break into the debugger. At that point, you can step through the client-side code and create new breakpoints in the normal way.

You can use the debugger to debug SQL stored procedures, functions, and triggers. You can debug these objects directly or in the context of executing an application.

For example, if you want to step through a stored procedure statement-by-statement, you can simply right-click the stored procedure in the Server Explorer window and select Step Into Stored Procedure. You can also step through a stored procedure when the stored procedure is open in the Code Editor by right-clicking the Code Editor and selecting Step Into Stored Procedure (see Figure 6.6).

Figure 6.6. Debugging a stored procedure.

The more interesting case is when you want to debug a stored procedure in the context of an executing ASP.NET Web application. Before you can do this, you must enable SQL debugging for the application:

After you complete these steps, you can place a breakpoint in a stored procedure and stop an executing ASP.NET application at that breakpoint. The debugger can move seamlessly between your ASP.NET code and the SQL statements in the stored procedure.

In the old days, you would track down errors in an ASP page by using the Response.Write() statement. If you weren’t sure about the current value of a variable at a certain point in your code, you would Response.Write() the value of the variable to the browser window.

The Response.Write() statement, used as a debugging tool, has some serious drawbacks. First, if you forget to remove a Response.Write() statement before you move your application into production, the whole world will see your debugging information. Second, you can’t use Response.Write() on a “live” Web application because, once again, everyone in the world will see your debugging information.

Instead of using Response.Write(), you can use the Trace.Warn() statement. Unlike the Response.Write() statement, you can hide the output of every Trace.Warn() statement in a page with a single switch. Furthermore, unlike the Response.Write() statement, the output of the Trace.Warn() statement only shows up on the local machine by default. That way, the rest of the world does not see your debugging information.

Perform the following steps to enable page-level tracing:

When the TestTrace.aspx page opens, you should see the page in Figure 6.7. Notice that additional information has been automatically appended to the bottom of the page.

Figure 6.7. Using page tracing.

The two most useful sections appended to the page are the Trace Information and Control Tree sections. The Trace Information section displays information about the Page Init, PreRender, SaveViewState, and Render events. It also displays any custom trace information that you outputted with the Trace.Warn() statement, so your custom message “A message from me!” appears in this section.

The Trace Information section displays execution speed statistics for each entry. It displays the time in seconds between the execution of the first entry and the current entry. It also displays the time in seconds between the previous entry and the current entry. You can use these statistics to identify slow code.

The Control Tree section shows all the controls contained in the current page. If you look in the control tree, you should see the TextBox, DataGrid, and Calendar controls that you added to the page. The Control Tree section displays the Render and View State size for each control.

By default, the trace information appears only when the page is opened on the same server as the Web server. This is both good and bad. It means that the rest of the world will not see your trace information when you are debugging a live Web application. However, it also means that you won’t see the trace information when developing an application on a remote machine.

You can configure your application to show trace information remotely by modifying the Web.Config file:

Trace.Warn("Trace Category 1", "A message from me!" );

Trace.Warn("Trace Category 1", "A message from me!" )

int zero = 0;
int results;

try
{
  results = 12 / zero;
}
catch (Exception ex)
{
  Trace.Warn("Exceptions", "An Error!", ex);
}

Dim zero As Integer = 0
Dim results As Integer

Try
  results = 12 / zero
Catch ex As Exception
  Trace.Warn("Exceptions", "An Error!", ex)
End Try

In a production application, you don’t want page tracing information to be displayed. However, if something has gone wrong with a page, you might want an easy way to display the trace information. For example, when a certain secret string is passed in the query string, you want the trace information to be displayed.

You can programmatically enable or disable page tracing with the Trace.IsEnabled property. You can use the following Page_Load method to enable tracing only when the query string trace=secret is passed to the page:

C#. 

private void Page_Load(object sender, System.EventArgs e)
{
  if (Request.QueryString[ "trace" ] == "secret")
    Trace.IsEnabled = true;
}

VB.NET. 

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
 MyBase.Load
  If Request.QueryString("trace") = "secret" Then
    Trace.IsEnabled = True
  End If
End Sub

For security reasons, you’ll want to be careful to use a closely guarded password instead of secret. Remember that it is possible to steal database passwords and other sensitive data when tracing is enabled.

Application tracing enables you to gather trace information for every page running in an application. When you enable application tracing, you can view trace information in a special page named Trace.axd.

If you open the Trace.axd page in your browser, you’ll receive an error. For security reasons, application tracing is disabled by default. Before you can use application tracing, you need to modify the Web.Config file:

After you complete these steps, open the Trace.axd page in a Web browser. You should see the page in Figure 6.8.

Figure 6.8. Using application tracing.

The Trace.axd page shows tracing information for 10 requests. After 10 requests, you must flush the current trace information by clicking the Clear Current Trace link at the top-right of the page.

If you open another page in the Web browser—for example, the TestTrace.aspx page that we created in the previous section—and return to the Trace.axd page, you’ll see a new entry that corresponds to the page that you requested. If you click View Details, you’ll see all the trace information generated for that page.

It’s important to note that the trace information will contain any custom trace messages that were created with the Trace.Warn() statement. This means that you can disable page tracing for a page but still be able to see your custom trace information for the page by opening the Trace. axd page.