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 ToolsInternet OptionsAdvanced. 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” check box below these items so that you’re notified as errors occur in a page. If this box isn’t checked, an icon will appear 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 check box is that you’ll find that many other websites have errors as you browse to them, so you may want to leave it unchecked when you’re not debugging your own applications.
Figure 9-7 shows what the Internet Explorer Advanced settings should look like to enable debugging.
Once debugging is enabled in Internet Explorer, an ASP.NET AJAX page can be debugged using several techniques. The following sections walk you through the options.
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 ViewScript Debugger from the Internet Explorer menu (see Figure 9-8). 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 9-8. If you select Open, you’ll be prompted to start using Visual Studio .NET as the debugger, as shown in Figure 9-9. If Visual Studio .NET is already open, you can begin debugging, or you can choose to start a new instance of Visual Studio .NET to use for debugging. If you select Break at Next Statement, nothing will happen 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 .NET Just-In-Time debugger.
The Sys.Debug.fail function accepts only one parameter that represents the reason for the failure. Listing 9-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.
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();
As you step through the code by pressing F11 (step into) or F10 (step over), you may be prompted to select the location of dynamically loaded script files needed by ASP.NET AJAX, or you may encounter an error that states “There is no source code available for the current location.” This occurs when you try to step into dynamically generated script code that was loaded using the ScriptResource.axd and WebResource.axd HTTP handlers, so in this case, there isn’t a separate physical file that Visual Studio can walk through. Although this problem can be frustrating at first, a simple tool that’s already part of Visual Studio .NET can alleviate this problem.
Visual Studio .NET 2005 SP1 helps resolve this issue: however, knowing how to deal with the error if it arises is still helpful.
Visual Studio .NET 2005 includes a very functional tool called the Script Explorer that can be used to navigate through scripts within a page. The Script Explorer can be used to load dynamic scripts in the editor so that you can step into them easily using the debugger and avoid the dreaded “There is no source code available for the current location” error. If you are prompted to load a script file, simply cancel the dialog box (or if you receive the aforementioned error, click OK). Select DebugWindowsScript Explorer (or press Ctrl+Alt+N) to view the Script Explorer window. Double-click the page currently being debugged to open it in the editor, and then double-click all of the other script files shown. This will open all of the files referenced by the page in Visual Studio .NET so that the debugger can access the necessary source code to allow for a rich debugging experience.
Figure 9-11 shows an example of the Script Explorer and the script files used in an ASP.NET AJAX-enabled page named Listing9-12.aspx.
You can also start a debug session directly in Visual Studio .NET 2005 much as you would when debugging VB.NET or C# code within an ASP.NET page. 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 but-ton (the button with the green arrow on it) on the debug toolbar to start Internet Explorer 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 debug windows such as the Autos, Locals, Watch, and Immediate as shown in Figure 9-12. By using these windows, you can quickly access variable data and drill down into your applications to see what is happening internally.
Although this section focuses on debugging features in Visual Studio .NET 2005, Visual Web Developer 2005 Express also has integrated debugging features that can be used to debug ASP.NET AJAX applications. While not as full-featured as the Visual Studio .NET 2005 debugger, it does have support for the Script Explorer, Locals, and Watch windows as well as several others.