Microsoft's ASP.NET AJAX framework provides a solid foundation for building efficient and high performance Web-based applications that can enhance the overall end user experience. No matter how good a development platform is, however, bugs and other issues can be introduced by developers and triggered by end users. Knowing how to quickly debug ASP.NET AJAX applications can greatly increase your productivity as a developer and reduce the amount of frustration experienced while tracking down 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):
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 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 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.
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 2). 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 2. If you select Open, you'll be prompted to start using Visual Studio .NET as the debugger, as shown in Figure 3. 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 1 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.
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 Debug-->Windows-->Script 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 5 shows an example of the Script Explorer and the script files used in an ASP.NET AJAX-enabled page named Listing9-12.aspx (also available in the code download for the book, Professional ASP.NET AJAX).
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 button (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 6. 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.
Debugging with Internet Explorer and the Microsoft Script Debugger
In cases where you don't have access to Visual Studio .NET 2005 but need to debug ASP.NET AJAX pages and associated scripts, the Microsoft Script Debugger can be used to view and debug scripts and step through code line by line. The Script Debugger has been around for several years as a stand-alone product that can run on a variety of Microsoft operating systems, including Windows NT 4, Windows 2000, Windows Server 2003, Windows XP, and Windows Vista. It can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=2f465be0-94fd-4569-b3c4-dffdf19ccd99&DisplayLang=en (this URL is, of course, subject to change).
Once installed, the Script Debugger is automatically triggered when you select View-->Script Debugger-->Open (or Break at Next Statement) from the Internet Explorer menu. While the Script Debugger isn't as robust as the debugger built into Visual Studio .NET 2005, it is very functional and can help identify problems encountered in ASP.NET AJAX applications. Figure 7 shows what the Script Debugger looks like in action.
You can view all of the scripts used in the page through the Running Documents window, and you can set and remove breakpoints by placing the cursor on the line where you'd like to set (or remove) a breakpoint and then selecting the appropriate icon on the toolbar. The hand icon sets breakpoints, and the hand with a red "X" over it removes breakpoints. Scripts that are dynamically loaded in the page through ScriptResource.axd and WebResource.axd don't present a problem and are directly accessible to step into without any extra effort on your part.
Once the Script Debugger is started, you can step through code by pressing F8, step over code by pressing Shift+F8, or step out of code by pressing Ctrl+Shift+F8. Alternatively, you can select the appropriate icons on the toolbar to step through the code. As you step through code, you can view variables and their values by using the Command Window. Type the variable name or object function that you want to call, and it will be displayed.
Figure 8 shows an example of the windows available in the Script Debugger.
While you can run Visual Studio .NET 2005 and the Microsoft Script Debugger on the same machine, if you uninstall the Script Debugger, you may notice that the Script Debugger menu entry no longer appears in Internet Explorer or that Visual Studio .NET doesn't handle calls to Sys.Debug.fail. This can be fixed by performing a repair on the Visual Studio .NET installation.