If you’ve done any kind of web development, you’ve probably stumbled upon (and hopefully used) the Internet Explorer plugin Web Development Helper (affectionately called WebDevHelper) created by uber-Microsoftie Nikhil Kothari. It’s a great tool for exploring the DOM, tracing HTTP requests and responses, and debugging ASP.NET pages. Further development of the tool seems to have been abandoned, or at least put on hold (the last release was August 2007), but it still remains a must-have debugging and testing tool for ASP.NET developers. A feature I’d like to highlight is its support for browsing and executing client-side ASP.NET AJAX libraries and functions from inside Internet Explorer.

WebDevHelper works in version 6+ of Internet Explorer. If you’re using an older version then please stop reading this blog post and go upgrade immediately! You can launch the plugin by clicking Tools | Explorer Bars | Web Development Helper (IE8) or Tools | Web Development Helper (older versions). It will launch at the bottom of the browser window.

To demonstrate the JavaScript testing features of WebDevHelper, I created the following simple ASP.NET web service.

namespace MyViewState.Services
{
    [ScriptService]
    [WebService]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    public class CustomerService : System.Web.Services.WebService
    {
        [WebMethod]
        public List<Customer> GetCustomers(int startIndex, int rowCount)
        {
            var context = new NorthwindDataContext();
            var customers = context.Customers.Skip(startIndex).Take(rowCount);
            return customers.ToList();
        }
    }
}

By adding a reference to the service in ScriptManager, a client-side proxy is automatically generated using the ASP.NET AJAX client library.

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Services>
        <asp:ServiceReference Path="~/Services/CustomerService.asmx" />
    </Services>
</asp:ScriptManager>

Browsing Client Script

To view the JavaScript classes available to you on a particular page, launch it in IE and open WebDevHelper. Click on the Script dropdown list and select Script Class Browser…

This will bring up another window displaying all of the JavaScript classes available, including the generated script proxy we just generated and the ASP.NET AJAX library members.

As you can see, a service proxy was generated called MyViewState.Services.CustomerService and the entities that are returned from that proxy were generated as a client-side class called MyViewState.Entities.Customer. When you click on the service proxy, you can browse the available methods and see the parameters that are expected when calling them. In the case of the CustomerService class, GetCustomers() was implemented as both a static and member method, and expects the parameters startIndex and rowCount, as well as some optional callback methods.

Executing Client Script

To instantiate the class and execute its methods, click on the Script dropdown menu again and select Show Script Console.

This will display the new script console in which I can create and execute JavaScript code. I’ll instantiate a new CustomerService object and call its GetCustomers() method, passing in the required arguments as well as an inline callback method to let me know how many records were returned.

Since this was a web service call, you’ll need to enable HTTP logging and switch to the HTTP log to see if the service was called and returned the data correctly. You can switch to the HTTP log by clicking the HTTP dropdown and selecting Show HTTP Logs and you can enable HTTP logging by selecting the Enable Logging checkbox. Double click on the web service call to view the request and response information. As you can see in the screenshot below, the call to GetCustomers() successfully returned several customer records.

Loading and Saving Scripts

So far I’ve shown you how to work with generated script, but what if you have your own JavaScript libraries that you want to test? You can import your JavaScript files using the Load Script link button to the right of the Script Console. Simply navigate to the file you want and click Open. This will load the contents into the console’s immediate window. It’s important to note that WebDevHelper only supports libraries implemented using ASP.NET AJAX or Script#.

In the screenshot above, I’ve imported a utility library I wrote and can load the library into my page by clicking Execute. If you’ve made changes to an imported script or written some new code in the immediate window, you can easily save it by clicking Save Script when using the Script Console.

Debugging Client Script

By now you might be wondering about the purpose of the empty area next to the immediate window. This area will display trace information for scripts using the window.debugService script API, which you can read more about in this tutorial. You can display debug information by calling window.debugService.trace() anywhere in your code. I’ve already loaded the ASP.NET AJAX utility library I opened previously, called MyViewState.Utilities.RegexValidator, into the page. This library has several methods for validating strings using regular expressions. If I call a method on the script, pass in a string, and save the return value, I can use window.debugService.trace() to view the results very easily in the trace window. I’ll call the library’s isValidEmailAddress() method and test it against some correct and incorrect email values for correctness.

The trace window also outputs trace information generated using the ASP.NET AJAX client-side Sys.Debug library. You can use Sys.Debug.trace() to display a single line, or Sys.Debug.traceDump()to display all of an object’s member hierarchically. Here’s the same example using Sys.Debug.trace():

Using Sys.Debug.traceDump()is incredibly helpful and much faster than going through and object and writing out all of its values manually. Here I’ve dumped the MyViewState.Utilities.RegexValidator object to the trace window and can see its contents by only having to make a single method call.

One final feature script debugging feature I’d like to mention is the ability to trap script errors. You can enabled script debugging by either selecting the Enable Debugging checkbox or select Enable Script Debugging from the Script dropdown menu in WebDevHelper. When debugging is enabled, any error will be displayed in a pop-up window, along with a stack trace showing you where the faulty function call originated. In the image below, a call to the set_emailAddressPattern() function in my regex utility library caused an exception to be thrown. As you can see from the stack trace, I erroneously passed in a null value to the function.

Wrap Up

Web Development helper is a great tool for debugging your client-side JavaScript code. If you’re already using the latest version of Internet Explorer then you can also use the new IE8 Developer Tools, which compliments WebDevHelper nicely with additional script debugging capabilities. And of course, there’s the wonderful Firebug for Firefox. I’ll cover these tools in future posts, but definitely check them out as they both have some great script debugging features.