15.4. Enabling Internet Explorer for Debugging

Debugging JavaScript has proven to be somewhat of a challenge and has resulted in many developers resorting to "alert-style" debugging to better understand how an application is working. Fortunately, Internet Explorer 6 or higher includes integrated debugging functionality that can be used to start a debug session and step through ASP.NET AJAX code with a debugging tool such as Visual Studio 2008. Learning how to leverage Internet Explorer debugging features can enhance your productivity and significantly minimize the amount of time you spend hunting down bugs and other issues.

The debug capabilities in Internet Explorer 6 or higher are disabled by default but can be turned on by going to Tools Internet Options Advanced. The Advanced tab defines two items that need to be unchecked (a check means you can't debug):

• Disable script debugging (Internet Explorer)

• Disable script debugging (Other)

Also, check the Display a notification about every script error checkbox below these items so that you're notified as errors occur in a page. If this box isn't checked, an icon appears in the lower-left corner of the browser; unless you click it, you may miss noting that a client-side error occurred. A side effect of checking this checkbox is that you'll find that many other Web sites have errors as you browse to them, so you may want to leave it unchecked when you're not debugging your own applications.

Figure 15-8 shows what the Internet Explorer 7 Advanced settings should look like to enable debugging.

Figure 15-8. Figure 15-8

Once debugging is enabled in Internet Explorer, an ASP.NET AJAX page can be debugged using Visual Studio 2008.

15.4.1. Debugging with Internet Explorer and Visual Studio 2008

You can start a debug session several different ways. One of the easiest ways is to use the built-in script debugging capabilities of Internet Explorer. To start a debug session for an ASP.NET AJAX page, navigate to the page that you'd like to debug and select View Script Debugger from the Internet Explorer menu (see Figure 15-9). For this to work, you must enable Internet Explorer for debugging as described in the previous section.

You'll be presented with two different options, Open and Break at Next Statement, as shown in Figure 15-9. If you select Open, you'll be prompted to start using Visual Studio as the debugger, as shown in Figure 15-10. If Visual Studio is already open, you can begin debugging, or you can choose to start a new instance of Visual Studio 2008 to use for debugging. If you select Break at Next Statement, nothing happens until an action is performed that causes script within the page (or script referenced by the page) to execute. Once script code is executed in Internet Explorer, you'll be prompted to use the Visual Studio Just-In-Time debugger.

Figure 15-9. Figure 15-9

Figure 15-10. Figure 15-10

Once Visual Studio 2008 is open and loaded you can set a breakpoint in the page on the line where you'd like to start debugging. Visual Studio 2008 allows breakpoints to be set directly within JavaScript code embedded inline within a page, which is a nice feature previously unavailable in Visual Studio 2005.

In addition to manually setting breakpoints in the code editor, you can also trigger one or more breakpoints using different techniques. The first technique requires that you add the JavaScript debugger statement directly into the code where you'd like to start a debug session. This will force a breakpoint to occur at runtime at that location of the debugger statement in the code. While this technique works, ASP.NET AJAX's Sys.Debug class (discussed in the previous section) is designed for this purpose and is a more appropriate choice for debugging AJAX applications. You can call the Sys.Debug class's fail function to trigger the debugger when a specific line of code is hit.

The Sys.Debug.fail function accepts only one parameter that represents the reason for the failure. Listing 15-12 shows an example of using the Sys.Debug.fail function to break into a debug session right before songs are added into an Album object.

Example 15-12. Using the Sys.Debug.fail function

var album = new Wrox.ASPAJAX.Samples.Album();
album.set_title("Sam's Town");
album.set_artist("The Killers");

//Force the debugger to appear
Sys.Debug.fail("Debug song additions");

album.addSong(new Wrox.ASPAJAX.Samples.Song(3,"When you were young"));
album.addSong(new Wrox.ASPAJAX.Samples.Song(7,"Uncle Johnny"));
$get("lblTitle").innerHTML = album.get_title();
$get("lblArtist").innerHTML = album.get_artist();

It's helpful to call Sys.Debug.fail to trigger a debug session when a line of JavaScript code is executed, but you must remember to remove all these calls before moving an application to a production environment, because it will always trigger the debugger when debugging is enabled in Internet Explorer. You can have two versions of your script (Microsoft does this with its debug and release scripts) and set the appropriate ScriptMode on the ScriptManager to determine which script is loaded at runtime, as discussed at the beginning of this chapter. Although this means that your code is duplicated, the release script can have all whitespace characters stripped out of it to minimize its size, while the debug script can provide an easy-to-read script that contains the necessary calls to the Sys.Debug class for debugging, tracing, assertions and other operations.

In addition to supporting breakpoints within inline scripts, Visual Studio 2008 also allows breakpoints to be set in external .js files. Figure 15-11 shows an example of JavaScript in a file named Listing15-12.js that has a breakpoint successfully set.

As you begin debugging a script and step into other scripts you'll notice that Visual Studio 2008 automatically loads the necessary scripts for you so that you can step into and out script files with ease. This is made possible by Visual Studio 2008's Script Documents window. Script Documents can be used to load dynamic scripts in the editor (including ASP.NET AJAX Library scripts) so that you can step into them easily using the debugger. Figure 15-12 shows an example of the Script Documents window and the script files used in an ASP.NET AJAX-enabled page named Listing15-12WithScriptFile.aspx. The Script Documents window appears at the top of the Solution Explorer during a Visual Studio 2008 debug session.

Figure 15-11. Figure 15-11

Figure 15-12. Figure 15-12

In addition to starting a debug session using Internet Explorer, you can also start a debug session directly in Visual Studio 2008 much as you would when debugging VB.NET or C# code. First, right-click the page you'd like to debug in the Solution Explorer and select Set As Start Page from the menu. Then press F5 or click the green play button (the button with the green arrow on it) on the debug toolbar to start Internet Explorer (assuming that it is set as your default browser) and display the page. Set your breakpoints in the separate script files, and then trigger the breakpoints by performing the action you'd like to debug in the browser.

As you step through code, you have full access to standard debugging windows such as the Autos, Locals, Watch, and Immediate as shown in Figure 15-13. By using these windows, you can quickly access variable data and drill down into your applications to see what is happening internally.

Figure 15-13. Figure 15-13

Although this section focuses on debugging features in Visual Studio 2008, Visual Web Developer 2008 Express also has integrated debugging features that can be used to debug ASP.NET AJAX applications.