One of the great improvements in Visual Basic 2005 is the enhanced debugging. For example, Microsoft is keen to remind you that Visual Studio 2005 now allows "edit and continue" debugging -- with some exceptions.
But debugging a web service using Visual Basic 2005 isn't as easy as it should be. While working on an unpublished new book for VB 2005 by Matthew McDonald (... it will be out real soon now ...), I learned a new tip about how to do that. With the kind permission of the publisher, No Starch Press, I'm going to pass that knowledge along to you.
But before I get into that, there is a problem with writing a tip like this into a short article that I need to explain. The problem is that I can't include EVERYTHING you need to know about writing a VB 2005 web service application. That's a book - not just a short article. So I will assume here that you already know how to write a VB 2005 web service and we'll just start with one that has already been written to explain how to debug it.
Another problem is that it's not easy to include readable code examples and illustrations "inline" in this type of article. So I'll include links to seperate pages instead. When you see something like ...
Link to Example
... click on it to see the illustration and be sure to click the "Back" button in your browser to return to the article.
So here's a very simple web service has been created in VB 2005.
When this service is invoked using the built-in Visual Studio testing capability, you get a single string returned:
It's possible to debug the entire web service from client to server and back again ... but only if you have things set up correctly. The first key can be seen in the Solution Explorer illustration (above). Note that both the web service and the client are set up as separate projects in the same solution. The client has been configured as the startup project (that's why it's in bold type). You do this by simply adding a new project to your solution in Visual Studio. (File > Add > New Project). Assume you start with the Web Service Project. Then add the client project and write the code for it exactly as you normally would.
In our case, we have called the web service with code that is as simple as the service itself.
The illustration shows the code, the design view of the form, and the running form after the button has been clicked to call the service.
One of the most valuable techniques used in debugging is to add a breakpoint to the code and then run the application up to the breakpoint. Lets add a breakpoint to this line of code in the web service:
Return "Greetings from the About Visual Basic Web Service"
But when the application is started, it doesn't break on this line of code in spite of the fact that the code must have been executed! The problem is that by default, Visual Studio only loads the debug symbols for the startup project, in this case ClientWSDebug.
The solution is to load both projects loaded when the application is started. To accomplish this, select the solution (WSDebug in this case) and right-click to display the context menu. Select Set Startup Projects .... Then display the Common Properties > Startup Project view and select Multiple Startup Projects. This will load both projects, and the debug symbols for both, when the application starts. You also have to select "Start" for both projects in the Action field.
There is one final setting that you will normally have to make. Since both projects load, the default test web page will normally be displayed in addition to the interface of your startup project. (In my testing, this actually depends on the sequence of the projects in Solution Explorer!) You can prevent this from happening by selecting the web service project Property Pages and then selecting Start Options. Select the radio button, "Don't open a page. Wait for a request from an external application." This keeps the web service from displaying the test web page.
The end result is that the breakpoint in the web service does halt the program on the breakpoint statement - just as it should.