Excerpt from Professional ASP.NET AJAX
Enabling Internet Explorer for Debugging ASP.NET AJAX
by Dan Wahlin
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):
- 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 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.
Figure 1 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.
Debugging with Internet Explorer and Visual Studio .NET 2005
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.
Once Visual Studio .NET is open and available for debugging, you
won't be able set a breakpoint if the script is embedded within the page.
Instead, you'll see a message at the bottom of the Visual Studio .NET status
bar that states "This is not a valid location for a breakpoint" when
you try to set the breakpoint. There are several ways to solve this problem.
the code where you'd like to start a debug session, which will force a
breakpoint to occur at runtime at that location in your code. However, ASP.NET
Sys.Debug class is designed for this purpose and is a
more appropriate choice for debugging AJAX applications. You can call the
fail function to
trigger the debugger when a specific line of code is hit.
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
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
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 runtimeruntime (as discussed in Chapter 9 "Testing and Debugging ASP.NET AJAX Applications," of Professional ASP.NET 2.0 AJAX (Wrox, 2007, ISBN: 978-0-470-10962-5)). 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
Another option for triggering the debugger when the script is
own script file, instead of including it directly in the .aspx page. In this
case, a separate file with an extension of .js is referenced by the page to be
loaded separately at runtime, instead of being sent down to the browser along
with the HTML markup. After you've done this you can set a breakpoint in the
in the code download for the book, Professional ASP.NET AJAX (Wrox, 2007, ISBN: 978-0-470-10962-5), that has a breakpoint successfully
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
can be fixed by performing a repair on the Visual Studio .NET installation.
This article is excerpted from Chapter 9 "Testing and Debugging ASP.NET AJAX Applications" of Professional ASP.NET 2.0 AJAX by Matt Gibbs and Dan Wahlin. Dan Wahlin (Microsoft Most Valuable Professional for ASP.NET and XMLWeb Services) is a .NET development instructor at Interface Technical Training (http://www.interfaceTraining.com). Dan founded the XML for ASP.NET Developers Website (www.XMLforASP.NET), which focuses on using XML, ADO.NET, and Web Services in Microsoft's .NET platform. He's also on the INETA Speakers Bureau and speaks at several conferences. Dan has co-authored/authored several different books on .NET, including ASP.NET 2.0 MVP Hacks and Tips and XML for ASP.NET Developers. When he's not writing code, articles, or books, Dan enjoys writing and recording music and playing golf and basketball with his wife and kids. Dan regularly blogs at http://weblogs.asp.net/dwahlin and http://blogs.interfacett.com/dan-wahlins-blog. Recent related Wrox articles of interest are Using the ASP.NET AJAX ScriptManager by Matt Gibbs also excerpted from Professional ASP.NET 2.0 AJAX and Ajax Debugging with Microsoft Fiddler by Nicholas C. Zakas excerpted from Professional Ajax 2nd Edition (Wrox, 2007, ISBN: 978-0-470-10949-6).