Miha Grčar

Testing .NET Web services remotely is disabled by default. This means that if you navigate to a Web service and select a method, you will not get the HTML form for testing the method unless this has been enabled as described in this article. The trick is to add the following section to Web.config:

<system.web>
<!--
The following enables access to the test forms
from a remote machine.
-->
<webServices>
<protocols>
<add name=″HttpGet″/>
<add name=″HttpPost″/>
</protocols>
</webServices>
...
</system.web>

Today I was struggling with the issue of developing and debugging a 32-bit .NET Web service on a 64-bit Windows platform (i.e. Windows Server 2003) in Visual Studio 2005. This is not entirely trivial so I decided to write about it.

The reason why I need a 32-bit service is because it is using a 32-bit unmanaged DLL which I cannot recompile for a 64-bit system. .NET assigns a 64-bit interpreter to a newly created Web service by default (due to the fact that the OS is 64-bit, I guess). This can be seen in Internet Information Services (IIS) Manager if you view the Web service properties and then select Configuration under Application settings. If you look at the executable paths for various application extensions, you can see “\Framework64\” as part of each path. The trick is to set all these paths to “\Framework\” instead. Apart from this it is also necessary to put IIS into the 32-bit mode and register the 32-bit version of ASP.NET. This article explains how to do this. In short, you launch the command prompt and issue the following commands:

• cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
• %SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -ir
• %SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -s W3SVC/1/ROOT/WebServiceName

As always after such actions, restarting IIS and the application pool is a smart thing to do

Unfortunately it is not possible to run a 32-bit and a 64-bit Web service at the same time on a 64-bit Windows platform

To debug my Web service, I added another project (a console-mode application, to be more exact) to the solution. In the pre-build event of this test application, I issue a command with which I generate the WSDL stub:

• "C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\wsdl" /language:cs /namespace:WebServiceName "/out:$(ProjectDir)WebServiceName.cs" /protocol:soap http://localhost/WebServiceName/Service.asmx?wsdl

Everything seemed OK until I pressed F5. I then realized that I cannot set breakpoints in the Web service source code after I set the test application to be the startup project. I resolved this issue by setting two startup projects, the Web service project and the test application project, as described in this article by Dan Mabbutt. To summarize, you need to follow these steps to prepare your solution for debugging:

1. Select Set Startup Projects from the solution context menu.
2. Tick the Multiple startup projects radio box and set the Action option for the Web service project and the test application project to Start.
3. Select Property Pages from the Web service project context menu and tick “Don’t open a page. Wait for a request from an external application.”
4. Start Internet Information Services (IIS) Manager, select the Directory Security tab, and press the Edit button under Authentication and access control.
5. Tick the Integrated Windows authentication check box.

This set almost everything right. The only issue still remaining was that I was unable to set breakpoints in the unmanaged DLL source code (which was also included in the solution as a separate project). It turned out that this one is easy to solve: you simply display Property Pages of the Web service, click Start Options, and tick the Native code check box in the Debugger section. Do not be alarmed if the breakpoints in the unmanaged code seem inactive right after launching the application − this will only be the case until the DLL gets loaded by the managed code.