Debugging Preparation

By default, a Web service runs under the standard ASPNET user account. This is really a security feature, in that this account is given limited permissions by default and so can do only a limited amount of damage if hijacked. The important issue from a debugging point of view is that a developer can only debug a process running under another user account (such as ASPNET) if that developer belongs to the Administrators group on the machine where the process is running. In other words, if you want to debug a Web service, it's not sufficient to just be in the Users and Debugger Users groups, as discussed at the beginning of Chapter 4.

To add user accounts to and remove user accounts from groups when using Windows 2000, go to the Control Panel and choose Administrative Tools ’ Computer Management ’ System Tools ’ Local Users and Groups ’ Groups. Windows XP and .NET Server also allow maintenance of users and groups from the Control Panel.

If you really don't want, or aren't allowed, to add the developer doing the debugging to the Administrators group, there's a workaround. You can tell the ASP .NET worker process to run under a specific developer's account by adding some entries to the .NET machine configuration file, machine.config. Security issues are involved with this approach, but full details on how to do it are in Chapter 9 if you need to adopt this procedure.

The TimeServer Web service serves as the demonstration application for this chapter. The TimeServer Visual Studio solution contains two projects. The first project is the TimeServer Web service, and the second project is a Windows Forms application called TimeServerClient .

After you load this solution into Visual Studio, you should check that the Web service project is configured for ASP .NET debugging. Right-click the TimeServer project in Solution Explorer, go to the Properties ’ Configuration Properties ’ Debugging property page, and make sure that the ASP .NET debugging option is selected.

On the same property page, you can specify how a Web service should be started for a debug or test session. This is controlled by the Start Action setting, which has four options:

• Start project : This option allows the Web service project to be started directly and accessed through its built-in test Web page. The default Web browser will be launched and point at the test page. This is the best option to use when you're doing unit testing of a Web service's methods , because it allows you to perform testing and debugging without having to write a custom client for the Web service.

• Start external program : Select this option if you want to test a Web service using another program as its client. When you choose this option, the Visual Studio debugger attaches to the Web service, but not to the external program that you're using to invoke the Web service.

• Start URL : You should choose this option only if you want to debug and test a Web service by invoking it from a specific Web page.

• Wait for an external process to connect : This option is similar to the "Start external program" option discussed previously, but the Visual Studio debugger attaches itself to both the Web service and the process that invokes the Web service. This option is most useful when you're testing and debugging the Web service and its client application together.

For the first demonstration, you should ensure that the Start Action setting is set to the first option (Start project) and that the start page is set to TimeService.asmx.

On the Properties ’ Configuration Properties ’ Build property page of the TimeServer and TimeServerClient projects, ensure that the "Generate debugging information" option is selected. This ensures that debug symbols will be generated for all precompiled components in the Web service and its client.

Next , use Solution Explorer to go to the solution's Properties ’ Common Properties ’ Startup Project property page and check that the Single Startup Project option is selected. The Multiple Startup Projects option on the same page should be used when the Web service to be debugged and its client exist in the same solution, as I demonstrate in the section "Debugging Using a SOAP Client" later in this chapter.

For the next preparation task, go to the Solution Explorer window and open the file named Web.config in the TimeServer project. This XML configuration file includes settings that control Web service behavior. Listing 8-1 shows the debug setting, though you will be looking at other Web.config settings when you examine Web service error handling later in this chapter.

Listing 8-1. The Debug Setting in TimeServer's Web.config

 <system.web>      <compilation defaultLanguage="vb" debug="true" /> </system.web> 

 

Setting this debug XML attribute to true tells Visual Studio to generate debug symbols for any dynamically generated page and insert them into the page. It also allows the Visual Studio debugger to attach to the Web service. The major reason to be wary about this setting is that enabling debugging will make the Web service run much slower than normal, so it's advisable to make sure that this attribute is set to false when you release a Web service into a production environment.

ASP .NET automatically detects any changes to Web.config, so you don't need to reboot or restart the server for changes to take effect. But be aware that these attribute names are case sensitive, so using Debug rather than debug won't work!

Still in Visual Studio, select Debug ’ Exceptions ’ Common Language Runtime Exceptions ’ System. Make sure that the "When the exception is thrown" option is set to "Continue" and the "If the exception is not handled" option is set to "Break into the debugger". (For a much more detailed explanation of these options, please see Chapter 13.) These settings ensure that when I start to demonstrate Web service exceptions later in this chapter, the Visual Studio debugger won't interrupt the flow of control unless it has no choice.