Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] نسخه متنی

Debugging Mobile Web Applications

When you build an application, the compiler ensures that the code defined in code-behind modules and other classes compiles correctly. Despite this compile-time syntax checking, several other types of errors can occur when you run your application:

Configuration errorsParsing errors that occur in one of the configuration files: machine.config in the C:/WINNT/Microsoft.NET/Framework/version/CONFIG directory, the server-wide Web.config file in the Web server root directory, or Web.config in the application directories.

ASP.NET parser errorsOccur when the server control syntax in an .aspx file is malformed.

Compilation errorsOccur when a coding error exists in code modules included with an .aspx file.

Run-time errorsCaused by unexpected behavior of your application logic, or situations you have not anticipated, such as the existence of null object references or division by zero.

By default, if a run-time error occurs in an ASP.NET application during execution, the runtime tries to report as much information about the error as possible on the requesting browser screen. The ASP.NET Mobile Controls Runtime ensures that the markup language the error page uses is appropriate for the client device. The runtime provides a shorter version of the error page on WML devices, as Figure 16-1 shows. A WML device that has a large display area displays a usable amount of error feedback on a single screen. However, if you use a device or an emulator that has only a small display, paging through the information to get the error details you need becomes tedious. For this reason, we advise using Microsoft Internet Explorer to perform initial application testing.

Figure 16-1: Detailed error reporting in Internet Explorer vs. a shorter version of the same report on the Openwave simulator

Configuring Applications to Support Debugging

If you've configured an application to support debugging, the ASP.NET error display offers details about the source line where the error occurred. A debugger process must be able to link executable code to its source to give detailed error reports and to perform other debugging functions, such as pausing at the code line where the developer has set a breakpoint.

Compiling the source code with debug symbols enables this link between the source and the executable code. Because many parts of an ASP.NET application dynamically compile at run time, you configure the application to compile for debugging by setting the debug attribute to true in the <compilation> element within Web.config, the application configuration file in the application root directory. Listing 16-1 shows the syntax for this technique.

Listing 16-1: Web.config file, including support for debug compilation

<?xml version="1.0" encoding="utf-8" ?>
<configuration>    
<system.web>
<!--  DYNAMIC DEBUG COMPILATION
Set compilation debug="true" to enable ASPX debugging.  
Otherwise, setting this value to
false will improve runtime performance of this application. 
-->
<compilation debug="true"/>
 
</system.web>
</configuration>

As the comment in Listing 16-1 suggests, when your application goes live, you should set the debug attribute to false. Leaving this attribute on creates a substantial performance overhead.

Visual Studio .NET has an integrated debugger that allows you to set breakpoints, step through code, and watch variables. This integrated debugger makes it easy to step into components and even into code running on remote machines, such as XML Web services, to examine the operation of your applications. If you're not using Visual Studio .NET, you can use the Common Language Runtime Debugger (cordbg.exe) that comes with the .NET Framework. You can run this debugger from the command line. Consult the .NET Framework SDK documentation for details on using these debuggers.