Instrumenting Web Services

Tips and Tricks for Debugging

Some of the information that can aid in your efforts to debug Web services does not clearly belong in any of the previous sections, so I present it in the following list:

• When you use Microsoft Internet Explorer to view documents that are automatically generated by the runtime (such as WSDL and results returned from the ASP.NET test harness), you should disable the display of friendly error messages, WSDL, and the results of any display-friendly error messages. Doing so will allow you to see the actual error message returned. Simply take the following steps:

1. In Internet Explorer, choose Tools, Internet Options.

2. On the Advanced tab of the Internet Options dialog box, deselect Show Friendly HTTP Error Messages.

• If Internet Explorer serves you a blank page, view the source. Sometimes an error message returned by the runtime will not display in the browser. To see these error messages, view the underlying source directly by clicking the View menu item and then selecting View Source.

• When you debug a Web service that is accessed through a proxy, you should increase the timeout value of the proxy to a large value. For ASP.NET proxies that derive from the SoapHttpClientProtocol class or for Remoting wrapped proxies that derive from the RemotingClientProxy class, set the Timeout property to -1 (infinity). Before you release the client application to production, be sure to set the timeout value back to a reasonable value.

• Visual Studio .NET allows you to debug multiple types of code within an application, including ASP, ASP.NET, unmanaged code, and SQL Server stored procedures. Make sure that the appropriate debugging options are selected within your project settings. For example, if you have an ASP.NET Web service that calls unmanaged code and you want to debug the entire implementation of the Web service, be sure to enable debugging support for both ASP.NET and unmanaged code.