<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>

A better solution is to start such legacy application as a Windows service. This article explains how to do this. These are the steps to follow:

1. Download Windows Server 2003 Resource Kit and install it into C:\reskit.
2. Start the command prompt and launch the following command:
   • C:\reskit\INSTSRV.EXE "<service name>"
C:\reskit\SRVANY.EXE
3. Start the registry editor and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service name>.
4. Add a key and name it Parameters.
5. Add the following value to the Parameters key:
   • Value name: Application
   • Data type: REG_SZ
   • String: <path>\<application.ext> <parameters>
     

This value represents the path to the executable file. It is also possible to specify command-line parameters here.

6. Start your service from Service Manager.

With these same tools, it is also possible to remove the service by issuing the following command:

• C:\reskit\INSTSRV.EXE "<service name>" REMOVE

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.