Debugging Using a Web Browser

Later in this chapter you'll look at debugging the TimeServer Web service while it's being called from the TimeServerClient application, but initially I want to look at calling the Web service from a Web browser. To do this, make sure that the Start Action setting is configured to the Start project option as discussed previously, and that the start page defined by this setting is TimeService.asmx. To check that everything compiles okay, you can now build the solution either by selecting Build ’ Build Solution or by pressing Ctrl+Shift+B (the default keyboard shortcut).

Assuming that the Web service compiled successfully, add a breakpoint on line 48 of the source code displayed in TimeService.asmx.vb. Listing 8-2 shows the code that makes up the CurrentTime Web method, and adding a breakpoint to line 48 (shown in bold in Listing 8-2) will enable the debugger to break into the CurrentTime method as soon as it's called.

Listing 8-2. The TimeService Class

 Option Strict On Imports System.Web.Services <Web.Services.WebService(Namespace:="http://debugvb .net/TimeServer/TimeService")> _ Public Class TimeService : Inherits System.Web.Services.WebService #Region " Web Services Designer Generated Code "       'Wizard-generated code omitted for brevity #End Region      <WebMethod()> _      Public Function CurrentTime() As String  Return System.DateTime.Now.ToLongTimeString  End Function End Class 

 

Before you start the service, if you're using Internet Explorer as your default Web browser, you should switch off its default "friendly" HTTP error handling. If you select Tools ’ Internet Options, and then go to the Browsing section of the Advanced tab, you'll see the option "Show friendly HTTP error messages". For the purposes of this demonstration, you can deselect this option. The difference between selecting and deselecting this option is the effect that a Web service exception has on the browser. If you opt for friendly HTTP error handling, the result of a Web service exception is the standard browser "Page cannot be displayed" message. If you turn off this option, the browser displays the actual exception message. I presume that "friendly" in this context means friendly to non-technical users.

Now start the TimeServer solution from Visual Studio by pressing F5. Visual Studio should open your default Web browser (Internet Explorer 6 in my case) and display the three public methods of the TimeService class: CurrentTime , ThrowExceptionRaw , and ThrowExceptionCustom . This page is provided by Visual Studio as a convenient way to test a Web service without having to write a custom client.

Click the CurrentTime method displayed in the browser and you'll see a new Web page that describes how this Web service method can be called using either a SOAP request or a raw HTTP POST and what the Web method will return as a response. Figure 8-1 shows the test page for the CurrentTime Web method.

Figure 8-1: Test Web page for the CurrentTime Web method

Most of the time, Web service clients use SOAP requests and responses, but a Web browser client uses a plain HTTP POST transmission. SOAP is the more common protocol because it provides true cross-platform support, more flexible data types (including Datasets), and support for SOAP headers and extensions that allow you to add features such as tracing and security. Most of the examples in this chapter use SOAP messages, because SOAP is the default in .NET.

If you switch back to Visual Studio and go to the Debug menu to select the Processes menu item, you can see what the Visual Studio debugger has done after you pressed F5. The Processes dialog window shows that the debugger has attached itself to the aspnet_wp.exe process, which is the ASP .NET worker process that I discussed at the beginning of this chapter. It's also attached itself to your Web browser process ”in my case iexplore.exe, because I'm using Internet Explorer. Figure 8-2 shows how this looks in Visual Studio.

Figure 8-2: Processes debugged by Visual Studio during a standard browser test

Going back to the Web browser test page, at long last you can click the Invoke button on the Web page that tests the CurrentTime Web method. The breakpoint that you placed inside the Web method will be triggered, and you can step through the Web service just like any other type of .NET application. When you step out of the CurrentTime Web method, your Web browser will show the XML document returned by the method. This should come as no surprise, because Web services are designed to communicate between components by using XML. Note that if you had used a SOAP client, the message returned would have been in SOAP format.

If you close the instance of your Web browser that shows the returned XML, you can click Back from the CurrentTime test page to go to the original Web service test page. Now click the link to the ThrowExceptionRaw method and you'll see a Web page that you can use to test that method. Once again, click the Invoke button. This time, your Web browser should show the text of the exception that this method throws, as shown in Listing 8-3.

Listing 8-3. Exception Produced by the ThrowExceptionRaw Web Method

 System.NullReferenceException:Object reference not set to an instance of an object.      at TimeServer.TimeService.ThrowExceptionRaw() in      c:\inetpub\wwwroot\TimeServer\TimeService.asmx.vb:line 55 

 

If you're using Internet Explorer, you can opt for friendly HTTP error handling as discussed previously. If you use this option with the ThrowExceptionRaw link, the result will be the standard browser "Page cannot be displayed" message. This demonstrates how a browser client deals with an unhandled exception thrown by a Web service. You'll look in more detail at Web service exceptions in the section "Handling Web Service Failure" later in this chapter.

Be aware that when you use Visual Studio to debug a client making an HTTP call to a Web service, an additional header is included in the POST request to allow the server and client to synchronize and do step-in debugging. This header includes the client computer name , and this information is always sent, even if there's no chance of a debugging connection between the client and server. This fact might be important if you're calling an untrusted Web service over an unsecured channel such as the Internet.