wsdl.exe problems

[heath.davies]

I have a scenario where I have thousands of web service clients all
referencing a URL of a .wsdl file generated by SOAP toolkit. I now need
to upgrade the backend of the web service (from SOAP toolkit C++)
without altering the client applications. I thought this was possible
using the wsdl.exe tool which comes with the .NET framework, however
once you have generated the server side code and added your
implementation the address of the .wsdl changes to <URL of .aspx
file>?WSDL. Therefore my question is this, can you use the .wsdl tool
to replace the implementation of a web service with .NET code without
altering the address the client uses to access the web service. (Note:
the clients are using the Microsoft SOAP toolkit to invoke the web
methods).

 

[John Saunders]

I have a scenario where I have thousands of web service clients all
referencing a URL of a .wsdl file generated by SOAP toolkit. I now need
to upgrade the backend of the web service (from SOAP toolkit C++)
without altering the client applications. I thought this was possible
using the wsdl.exe tool which comes with the .NET framework, however
once you have generated the server side code and added your
implementation the address of the .wsdl changes to <URL of .aspx
file>?WSDL. Therefore my question is this, can you use the .wsdl tool
to replace the implementation of a web service with .NET code without
altering the address the client uses to access the web service. (Note:
the clients are using the Microsoft SOAP toolkit to invoke the web
methods).

What do you mean that the address of the WSDL file changed? .NET will have
added the ?WSDL address, but the old one should certainly still be there.

Also, you probably want your clients to see your existing WSDL and not one
generated by ASP.NET. So, remove the "documentation" protocol:

<system.web>
<webServices>
<protocols>
<remove name="Documentation"></remove>
<remove name="HttpGet"></remove>
<remove name="HttpPost"></remove>
</protocols>
</webServices>
</system.web>

This will also get rid of two other protocols you probably don't want.

Then just tell your clients to get the WSDL from teh same place as before.

John

 

[heath.davies]

Ok, but how do you actually go about this? I cannot find any
documentation whcih gives you a real step by step approach including
the deployment. At the moment I have a website which contains the old
WSDL, let's call it HelloService. I've generated the server .net code
using wsdl.exe and built a binary, say HelloServiceDotNet.dll. What
would I then do to ensure that requests made from my SoapToolkit
clients to the old WSDL end up going to the .NET code in
HelloServiceDotNet.dll?

 

[John Saunders]

Ok, but how do you actually go about this? I cannot find any
documentation whcih gives you a real step by step approach including
the deployment. At the moment I have a website which contains the old
WSDL, let's call it HelloService. I've generated the server .net code
using wsdl.exe and built a binary, say HelloServiceDotNet.dll. What
would I then do to ensure that requests made from my SoapToolkit
clients to the old WSDL end up going to the .NET code in
HelloServiceDotNet.dll?

Your clients don't make calls to the WSDL, they make calls to the web
service described by the WSDL. Change the location attribute in the
<soap:address> element inside of <wsdlort> inside of <wsdl:service>. Have
it point to the new URL, and the clients should be using the new one.

John