Debugging ASP.NET AJAX Applications potx

19 190 0
Debugging ASP.NET AJAX Applications potx

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Debugging ASP.NET AJAX Applications Dan Wahlin The ability to debug code is a skill that every developer should have in their arsenal regardless of the technology they’re using. It goes without saying that understanding the different debugging options that are available can save a tremendous amount of time on a project and perhaps even a few headaches. While many developers are accustomed to using Visual Studio .NET or Web Developer Express to debug ASP.NET applications that use VB.NET or C# code, some aren’t aware that it’s also extremely useful for debugging client-side code such as JavaScript. The same type of techniques used to debug .NET applications can also be applied to AJAX-enabled applications and more specifically ASP.NET AJAX applications. In this article you’ll see how Visual Studio 2008 Beta 2 and several other tools can be used to debug ASP.NET AJAX applications to quickly locate bugs and other issues. This discussion will include information about enabling Internet Explorer 6 or higher for debugging, using Visual Studio 2008 and the Script Explorer to step through code as well as using other free tools such as Web Development Helper. You’ll also learn how to debug ASP.NET AJAX applications in Firefox using an extension named Firebug which lets you step through JavaScript code directly in the browser without any other tools. Finally, you’ll be introduced to classes in the ASP.NET AJAX Library that can help with various debugging tasks such as tracing and code assertion statements. Before you try to debug pages viewed in Internet Explorer there are a few basic steps you’ll need to perform to enable it for debugging. Let’s take a look at some basic setup requirements that need to be performed to get started. Configuring Internet Explorer for Debugging Most people aren’t interested in seeing JavaScript issues encountered on a Website viewed with Internet Explorer. In fact, the average user wouldn’t even know what to do if they saw an error message. As a result, debugging options are turned off by default in the browser. However, it’s very straightforward to turn debugging on and put it to use as you develop new AJAX applications. To enable debugging functionality, go to Tools  Internet Options on the Internet Explorer menu and select the Advanced tab. Within the Browsing section ensure that the following items are unchecked: Disable script debugging (Internet Explorer) Disable script debugging (Other) Although not required, if you’re trying to debug an application you’ll probably want any JavaScript errors in the page to be immediately visible and obvious. You can force all errors to be shown with a message box by checking the "Display a notification about every script error" checkbox. While this is a great option to turn on while you’re developing an application, it can quickly become annoying if you’re just perusing other Websites since your chances of encountering JavaScript errors are pretty good. Figure 1 shows what the Internet Explorer advanced dialog should look after it has been properly configured for debugging. Figure 1. Configuring Internet Explorer for debugging. Once debugging has been turned on, you’ll see a new menu item appear in the View menu named Script Debugger. It has two options available including Open and Break at Next Statement. When Open is selected you’ll be prompted to debug the page in Visual Studio 2008 Beta 2 (note that Visual Web Developer Express can also be used for debugging). If Visual Studio .NET is currently running you can choose to use that instance or to create a new instance. When Break at Next Statement is selected you’ll be prompted to debug the page when JavaScript code is executed. If JavaScript code executes in the onLoad event of the page you can refresh the page to trigger a debug session. If JavaScript code is run after a button is clicked then the debugger will run immediately after the button is clicked. Note: if you are running on Windows Vista with User Access Control (UAC) enabled, and you have Visual Studio 2008 set to run as an administrator, Visual Studio will fail to attach to the process when you are prompted to attach. To work around this issue, start Visual Studio first, and use that instance to debug. Although the next section will demonstrate how to debug an ASP.NET AJAX page directly from within Visual Studio 2008, using the Internet Explorer Script Debugger option is useful when a page is already open and you’d like to more fully inspect it. Debugging with Visual Studio 2008 Beta 2 Visual Studio 2008 Beta 2 provides debugging functionality that developers around the world rely on everyday to debug .NET applications. The built-in debugger allows you to step through code, view object data, watch for specific variables, monitor the call stack plus much more. In addition to debugging VB.NET or C# code, the debugger is also helpful for debugging ASP.NET AJAX applications and will allow you to step through JavaScript code line by line. The details that follow focus on techniques that can be used to debug client-side script files rather than providing a discourse on the overall process of debugging applications using Visual Studio 2008. The process of debugging a page in Visual Studio 2008 can be started in several different ways. First, you can use the Internet Explorer Script Debugger option mentioned in the previous section. This works well when a page is already loaded in the browser and you’d like to start debugging it. Alternatively, you can right-click on an .aspx page in the Solution Explorer and select Set As Start Page from the menu. If you’re accustomed to debugging ASP.NET pages then you’ve probably done this before. Once F5 is pressed the page can be debugged. However, while you can generally set a breakpoint anywhere you’d like in VB.NET or C# code, that’s not always the case with JavaScript as you'll see next. Embedded Versus External Scripts The Visual Studio 2008 debugger treats JavaScript embedded in a page different than external JavaScript files. With external script files, you can open the file and set a breakpoint on any line you choose. Breakpoints can be set by clicking in the grey tray area to the left of the code editor window. When JavaScript is embedded directly into a page using the <script> tag, setting a breakpoint by clicking in the grey tray area isn’t an option. Attempts to set a breakpoint on a line of embedded script will result in a warning that states "This is not a valid location for a breakpoint". You can get around this issue by moving the code into an external .js file and referencing it using the src attribute of the <script> tag: <script type="text/javascript" What if moving the code into an external file isn’t an option or requires more work than it's worth? While you can’t set a breakpoint using the editor, you can add the debugger statement directly into the code where you’d like to start debugging. You can also use the Sys.Debug class available in the ASP.NET AJAX library to force debugging to start. You’ll learn more about the Sys.Debug class later in this article. An example of using the debugger keyword is shown in Listing 1. This example forces the debugger to break right before a call to an update function is made. Listing 1. Using the debugger keyword to force the Visual Studio .NET debugger to break. function BuildPerson() { var person = { FirstName: $get("txtFirstName").value, LastName: $get("txtLastName").value, Address: { Street: $get("txtStreet").value, City: $get("txtCity").value, State: $get("txtState").value } }; debugger; UpdatePerson(person); } Once the debugger statement is hit you will be prompted to debug the page using Visual Studio .NET and can begin stepping through the code. While doing this you may encounter an issue with accessing ASP.NET AJAX library script files used in the page so let's take a look at using Visual Studio .NET's Script Explorer. Using Visual Studio .NET Windows to Debug Once a debug session is started and you begin walking through code using the default F11 key, you may encounter the error dialog shown in see Figure 2 unless all script files used in the page are open and available for debugging. Figure 2. Error dialog shown when no source code is available for debugging. This dialog is shown because Visual Studio .NET isn't sure how to get to the source code of some of the scripts referenced by the page. While this can be quite frustrating at first, there's a simple fix. Once you have started a debug session and hit a breakpoint, go to the Debug  Windows  Script Explorer window on the Visual Studio 2008 menu or use the Ctrl+Alt+N hotkey. Note: If you can’t see the Script Explorer menu listed, go to Tools  Customize  Commands on the Visual Studio .NET menu. Locate the Debug entry in the Categories section and click it to show all available menu entries. In the Commands list, scroll down to Script Explorer and then drag it up onto the Debug  Windows menu in mentioned earlier. Doing this will make the Script Explorer menu entry available each time you run Visual Studio .NET. The Script Explorer can be used to view all scripts used in a page and open them in the code editor. Once the Script Explorer is open, double-click on the .aspx page currently being debugged to open it in the code editor window. Perform the same action for all of the other scripts shown in the Script Explorer. Once all of the scripts are open in the code window you can press F11 (and use the other debug hotkeys) to step through your code. Figure 3 shows an example of the Script Explorer. It lists the current file being debugged (Demo.aspx) as well as two custom scripts and two scripts dynamically injected into the page by the ASP.NET AJAX ScriptManager. Figure 3. The Script Explorer provides easy access to scripts used in a page. Several others windows can also be used to provide useful information as you step through code in a page. For example, you can use the Locals window to see the values of different variables used in the page, the Immediate window to evaluate specific variables or conditions and view the output. You can also use the Output window to view trace statements written out using the Sys.Debug.trace function (which will be covered later in this article) or Internet Explorer’s Debug.writeln function. As you step through code using the debugger you can mouse over variables in the code to view the value that they are assigned. However, the script debugger occasionally won’t show anything as you mouse over a given JavaScript variable. To see the value, highlight the statement or variable you’re trying to see in the code editor window and then mouse over it. Although this technique doesn’t work in every situation, many times you will be able to see the value without having to look in a different debug window such as the Locals window. A video tutorial demonstrating some of the features discussed here can be viewed at http://www.xmlforasp.net . Debugging With Web Development Helper Although Visual Studio 2008 (and Visual Web Developer Express 2008) are very capable debugging tools, there are additional options that can be used as well which are more light-weight. One of the latest tools to be released is the Web Development Helper. Microsoft’s Nikhil Kothari (one of the key ASP.NET AJAX architects at Microsoft) wrote this excellent tool which can perform many different tasks from simple debugging to viewing HTTP request and response messages. Web Development Helper can be downloaded at http://projects.nikhilk.net/Projects/WebDevHelper.aspx . Web Development helper can be used directly inside of Internet Explorer which makes it convenient to use. It’s started by selecting Tools  Web Development Helper from the Internet Explorer menu. This will open the tool in the bottom portion of the browser which is nice since you don’t have to leave the browser to perform several tasks such as HTTP request and response message logging. Figure 4 shows what Web Development Helper looks like in action. Figure 4. Web Development Helper Web Development helper isn’t a tool you’ll use to step through code line by line as with Visual Studio 2008. However, it can be used to view trace output, easily evaluate variables in a script or explore data is inside of a JSON object. It’s also very useful for viewing data that is passed to and from an ASP.NET AJAX page and a server. Once Web Development Helper is open in Internet Explorer, script debugging must be enabled by selecting Script  Enable Script Debugging from the Web Development helper menu as shown earlier in Figure 4. This enables the tool to intercept errors that occur as a page is run. It also allows easy access to trace messages that are output in the page. To view trace information or execute script commands to test different functions within a page, select Script  Show Script Console from the Web Development Helper menu. This provides access to a command window and a simple immediate window. Viewing Trace Messages and JSON Object Data The immediate window can be used to execute script commands or even load or save scripts that are used to test different functions in a page. The command window displays trace or debug messages written out by the page being viewed. Listing 2 shows how to write a trace message using Internet Explorer’s Debug.writeln function. Listing 2. Writing out a client-side trace message using the Debug class. function BuildPerson() { var person = { FirstName: $get("txtFirstName").value, LastName: $get("txtLastName").value, Address: { Street: $get("txtStreet").value, City: $get("txtCity").value, State: $get("txtState").value } }; Debug.writeln("Person name: " + person.LastName); UpdatePerson(person); } If the LastName property contains a value of Doe, Web Development Helper will display the message "Person name: Doe" in the script console’s command window (assuming that debugging has been enabled). Web Development Helper also adds a top-level debugService object into pages that can be used to write out trace information or view the content of JSON objects. Listing 3 shows an example of using the debugService class’s trace function. Listing 3. Using Web Development Helper’s debugService class to write a trace message. function BuildPerson() { var person = { FirstName: $get("txtFirstName").value, LastName: $get("txtLastName").value, Address: { Street: $get("txtStreet").value, City: $get("txtCity").value, State: $get("txtState").value } }; if (window.debugService) { window.debugService.trace("Person name: " + person.LastName); } UpdatePerson(person); } A nice feature of the debugService class is that it will work even if debugging isn’t enabled in Internet Explorer making it easy to always access trace data when Web Development Helper is running. When the tool isn’t being used to debug a page, trace statements will be ignored since the call to window.debugService will return false. The debugService class also allows JSON object data to be viewed using Web Development Helper’s inspector window. Listing 4 creates a simple JSON object containing person data. Once the object is created, a call is made to the debugService class’s inspect function to allow the JSON object to be visually inspected. Listing 4. Using the debugService.inspect function to view JSON object data. function BuildPerson() { var person = { FirstName: $get("txtFirstName").value, LastName: $get("txtLastName").value, Address: { Street: $get("txtStreet").value, City: $get("txtCity").value, State: $get("txtState").value } }; if (window.debugService) { window.debugService.inspect("Person Object",person); } UpdatePerson(person); } Calling the GetPerson() function in the page or through the immediate window will result in the Object Inspector dialog window appearing as shown in Figure 5. Properties within the object can be changed dynamically by highlighting them, changing the value shown in the Value text box and then clicking the Update link. Using the Object Inspector makes it straightforward to view JSON object data and experiment with applying different values to properties. Debugging Errors In addition to allowing trace data and JSON objects to be displayed, Web Development helper can also aid in debugging errors in a page. If an error is encountered, you will be prompted to continue to the next line of code or debug the script (see Figure 6). The Script Error dialog window shows the complete call stack as well as line numbers so you can easily identify where issues are within a script. Figure 5. Using the Object Inspector window to view a JSON object. Selecting the debug option allows you to execute script statements directly in Web Development Helper’s immediate window to view the value of variables, write out JSON objects, plus more. If the same action that triggered the error is performed again and Visual Studio 2008 is available on the machine, you will be prompted to start a debug session so that you can step through the code line by line as discussed in the previous section. Figure 6. Web Development Helper’s Script Error Dialog Inspecting Request and Response Messages While debugging ASP.NET AJAX pages it is often useful to see request and response messages sent between a page and server. Viewing the content within messages allows you to see if the proper data is being passed as well as the size of the messages. Web Development Helper provides an excellent HTTP message logger feature that makes it easy to view data as raw text or in a more readable format. To view ASP.NET AJAX request and response messages, the HTTP logger must be enabled by selecting HTTP  Enable HTTP Logging from the Web Development Helper menu. Once enabled, all messages sent from the current page can be viewed in the HTTP log viewer which can be accessed by selecting HTTP  Show HTTP Logs. Although viewing the raw text sent in each request/response message is certainly useful (and an option in Web Development Helper), it is often easier to view message data in a more graphical format. Once HTTP logging has been enabled and messages have been logged, message data can be viewed by double-clicking on the message in the HTTP log viewer. Doing this allows you to view all headers associated with a message as well as the actual message content. Figure 7 shows an example of a request message and response message viewed in the HTTP Log Viewer window. Figure 7. Using the HTTP Log Viewer to view request and response message data. The HTTP Log Viewer automatically parses JSON objects and displays them using a tree view making it quick and easy to view the object’s property data. When an UpdatePanel is being used in an ASP.NET AJAX page, the viewer breaks out each portion of the message into individual parts as shown in Figure 8. This is a great feature that makes it much easier to see and understand what is in the message as compared to viewing the raw message data. [...]... inspecting different elements within the page Debugging Support in ASP.NET AJAX The ASP.NET AJAX library includes many different classes that can be used to simplify the process of adding AJAX capabilities into a Webpage You can use these classes to locate elements within a page and manipulate them, add new controls, call Web Services and even handle events The ASP.NET AJAX library also contains classes that... you can more easily debug applications and simplify the overall process The ASP.NET AJAX library's release scripts are rather difficult to step through and read since code formatting has been removed while the debug scripts are formatted specifically for debugging purposes Conclusion Microsoft’s ASP.NET AJAX technology provides a solid foundation for building AJAX- enabled applications that can enhance... (http://www.interfacett.com ) Dan founded the XML for ASP.NET Developers Web site (www.XMLforASP.NET ), is on the INETA Speaker's Bureau and speaks at several conferences Dan co-authored Professional Windows DNA (Wrox), ASP.NET: Tips, Tutorials and Code (Sams), ASP.NET 1.1 Insider Solutions, Professional ASP.NET 2.0 AJAX (Wrox), ASP.NET 2.0 MVP Hacks and authored XML for ASP.NET Developers (Sams) When he’s not writing... including writing trace output, performing code assertions and forcing code to fail so that it can be debugged It is used extensively in the ASP.NET AJAX library’s debug files (installed at C:\Program Files\Microsoft ASP.NET\ ASP.NET 2.0 AJAX Extensions\v1.0.61025\MicrosoftAjaxLibrary\System.Web.Extensions\1.0.61025.0 by default) to perform conditional tests (called assertions) that ensure parameters are passed... particular line so you can inspect the value of variables Understanding the ScriptManager Control's ScriptMode Property The ASP.NET AJAX library includes debug and release script versions that are installed at C:\Program Files\Microsoft ASP.NET\ ASP.NET 2.0 AJAX Extensions\v1.0.61025\MicrosoftAjaxLibrary\System.Web.Extensions\1.0.61025.0 by default The debug scripts are nicely formatted, easy to read and have... certainly arise Knowing about the different debugging options available can save a lot of time and result in a more stable product In this article you’ve been introduced to several different techniques for debugging ASP.NET AJAX pages including Internet Explorer with Visual Studio 2008, Web Development Helper and Firebug These tools can simplify the overall debugging process since you can access variable... release version of ASP.NET AJAX library scripts When debug is true the debug version of the scripts will be loaded Changing the ScriptMode property to Release or Debug will force the ScriptManager to load the appropriate scripts regardless of what value the debug attribute has in web.config Listing 8 shows an example of using the ScriptManager control to load debug scripts from the ASP.NET AJAX library Listing... code line by line and view trace statements In addition to the different debugging tools discussed, you also saw how the ASP.NET AJAX library’s Sys.Debug class can be used in an application and how the ScriptManager class can be used to load debug or release versions of scripts Bio Dan Wahlin (Microsoft Most Valuable Professional for ASP.NET and XML Web Services) is a NET development instructor and architecture... thoroughly inspect message headers and data Debugging with Firefox and Firebug While Internet Explorer is still the most widely used browser, other browsers such as Firefox have become quite popular and are being used more and more As a result, you’ll want to view and debug your ASP.NET AJAX pages in Firefox as well as Internet Explorer to ensure that your applications work properly Although Firefox... with Microsoft Web technologies since 1997 and is the President of myKB.com (www.myKB.com) where he specializes in writing ASP.NET based applications focused on Knowledge Base Software solutions Scott can be contacted via email at scott.cate@myKB.com or his blog at http://weblogs .asp.net/ scottcate . It is used extensively in the ASP. NET AJAX library’s debug files (installed at C:Program FilesMicrosoft ASP. NET ASP. NET 2.0 AJAX Extensionsv1.0.61025MicrosoftAjaxLibrarySystem.Web.Extensions1.0.61025.0. Property The ASP. NET AJAX library includes debug and release script versions that are installed at C:Program FilesMicrosoft ASP. NET ASP. NET 2.0 AJAX Extensionsv1.0.61025MicrosoftAjaxLibrarySystem.Web.Extensions1.0.61025.0. The same type of techniques used to debug .NET applications can also be applied to AJAX- enabled applications and more specifically ASP. NET AJAX applications. In this article you’ll see how

Ngày đăng: 08/08/2014, 19:20

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan