Refreshing a SOAP WSDL import file with Delphi

I’m consuming a web service from a Delphi desktop app and both the web service and the desktop app are being developed at the same time.   Because the WSDL generated by the web service can change, I need to refresh the service interface code that the Delphi code uses to access the web service.  It corresponds to the web references class that a .NET app would use to consume a web service.

You typically create the web service interface code by bringing up the WSDL Import Wizard from the File->New->Other menu in Delphi.  You get a dialog that prompts you for the location of the WSDL file or URL.  From the WSDL, it generates a unit with interfaces defined for the classes and objects exposed by the web service.  It creates the file with the name of the service, plus “.pas”.

It works pretty well, but if you need to refresh that file due to changes in the web service, you don’t need to use that wizard to update the file.  There is a command line tool that will generate a new output file from a specificied WSDL.  This tool is named WSDLImp.exe, and is located in the bin folder of your Delphi installation.

The typical syntax is

WSDLImp.exe -P http://localhost/somefolder/someservice.asmx?WSDL

That will generate a file named someservice.pas.  If you want to specify a different name for the file, you can use the “-=” command line parameter like this”

WSDLImp.exe -P -= http://localhost/somefolder/someservice.asmx?WSDL=myservice.pas

That will create the file myservice.pas.  Very handy if you want to use a different name than the default.  Now when you update the service interface, you can just run WSDLImp to reimport the web service interface.

Using the test form from remote connections for .NET web services

I’m working on a web service using C# and targeting the .NET 2.0 Framework.  Nothing terribly fancy, but it has some code to log the caller’s IP address (via HttpContext.Current.Request.UserHostAddress).  While testing the code, I like using the test form functionality that .NET provides with web services.  By design, it only works locally.  If you try to use the test form from a remote machine, you’ll get the error:

The test form is only available for requests from the local machine

That’s fine, when you expose a web service you don’t want to make it too easy for people to start poking at your web service methods with a pointy stick.  Still, I wanted to test it from another machine and it saves time being able to enter in different values without having to code up a test framework.  Plus, I wanted to make sure that my code was reliably picking up the caller’s IP address.

After just a tiny bit of searching in the series of tubes, I found how to easily enable the web service test form for remote connections.  Juan Ignacio Gelos posted what you need to add to the web service web.config file to enable the test form.

<add name="HttpGet"/>
<add name="HttpPost"/>

You are still limited to run methods that have simple data types as input, but it’s very handy for testing.  Since this setting lives in web.config, it’s easy to remove it when I run a build.  I’m using FinalBuilder on a dedicated build box and it’s easy to clean up .config files so that developer settings get scrubbed before the files get packages into an installer.