09 - Debugging Web Services

Hi,

Here we’ll learn the approaches of Debuging XML Web Services.

Interactive Debugging

One of the most powerful tools in a developer’s arsenal is the debugger. A debugger allows you to attach to a process, peer into its state, and, depending on the debugger, even control the flow of the application. If the debugger supports remote debugging, the target process can be located on another machine.

You have many choices of debuggers for your .NET Web services. The .NET Framework ships with two debuggers, the CLR Debugger (DbgCLR.exe), which is Microsoft Windows based, and the Runtime Debugger (CorDbg.exe), which is command-line based. Visual Studio .NET also has its own debugger. In addition, you can choose from a number of thirdparty debuggers.

Debugging an XML Web Services:

You can debug XML Web services During Development or After Deployment.

To debug an XML Web service During Development, simply set the breakpoint and make a call the Web Methods.

To debug an XML Web service After Deployment, you need to take the help of DbgClr and execute below steps.

· Open the XML Web service in Internet Explorer by entering the URL for the .asmx file, such as http://localhost/MathService/MathService.asmx.

· From the Debug menu in Visual Studio .NET, choose Processes to open the Processes dialog box.

· Select aspnet_wp.exe from the Process list and click the Attach button, which opens the Attach To Process dialog box

· In the Attach To Process dialog box, select Common Language Runtime as the program type to debug and select the program that you want to debug, in this case MathService. Click OK, and then click the Close button to close the Processes dialog box.

· From the File menu in Visual Studio .NET, point to Open, and click File. In the Open File dialog box, select the code-behind file, such as the MathService.asmx.vb or MathService.asmx.cs file, located in the Inetpub\Wwwroot\MathService folder.

· Set breakpoint(s) in the code. In the MathService example, set a breakpoint on the line containing the divide method.

· In Internet Explorer, click the Divide link to display a new page where you can pass parameters to the divide method. Pass the values for the n1 and n2 parameters, and click the Invoke button.

· The debugger breaks the execution at the breakpoint set on the line containing the divide method.

· Use debug windows such as Autos, Locals, and Watch to examine the variables and their values.

· To stop debugging, choose Stop Debugging from the Debug menu.

Remote Debugging

To facilitate some of the remote debugging features required is - To install the Remote Debugging Components, insert the Visual Studio .NET setup disk into the target computer and select the Remote Components Setup link at the bottom of the opening screen.

Once installed, make sure that you have sufficient permissions to Attach to and Debug the target process on the remote machine. In order to simplify this process, Setup creates a local group on the target machine called Debugger Users. Users added to the Debugger Users group will have sufficient permissions to conduct a remote interactive debugging session. However, they also need permissions to attach to the

process itself.

One of the unique requirements for debugging Web services is strong support for remote debugging. The key features that Visual Studio .NET provides for supporting remote debugging include these:

· Visual Studio .NET automatically attaches to the remote ASP.NET process hosting the Web service.

· It allows you to configure the target server to allow remote debugging.

· It can display a logical call stack that spans multiple threads.

· It ensures that you get a complete call stack when an unhandled exception occurs within your application.

Instrumenting Web Services

Although source-level debugging is very powerful for debugging applications, in plenty of situations it is not practical. For example, if you interactively debug an ASP.NET Web service, you effectively block all threads from servi cing other requests. This is not very practical if the Web service is being hosted in a production environment and you have no ability to isolate it.

In such situations, instrumentation can be invaluable. Instrumentation is the process of generating the information about the running state of your Web service.

The .NET Framework offers developers belwo options for instrumenting Web services and the applications that consume them - Tracing, the Event Log, and performance counters.

Tracing	· Tracing is the process of recording key events during the execution of an application over a discrete period of time. · This information can help you understand the code path taken within the application. · Tracing information can also contain information about the changes made to the state of the application.
Event Log	· The Event Log provides a common repository for storing events from multiple sources. By default, the system has three logs: the Application Log, the Security Log, and the System Log. ·
Performance Counters	· The above two instrumentation methods are lasynchronous forms of communication. i.e. The application writes data to a text file or the Event Log, and then the client opens the information source and reads the data · However, at times the client might need to monitor the state of the application in real time. For e.g. knowing the number of requests per second that my Web service receives. Information such as this can be communicated using performance counters.

Hope this helps.

Thanks & Regards,

Arun Manglick || Senior Tech Lead