Differences in WSDL between versions of a web service.

[rusmo1]

I have 2 versions of a C# 1.1 web service that emit different WSDL, and
I would like to know what I may have done to cause this change, and
what effect it might have on my client apps.

The original verison's WSDL contains sections for each web service
function by name appended with HttpGetIn, HttpGetOut, HttpPostIn, and
HttpPostOut. For example, for the web service function "Init", I have
corresponding "InitHttpGetIn", "InitHttpGetOut", "InitHttpPostIn" and
"InitHttpPostOut" sections in the WSDL.

The new version of the web service's WSDL is missing these sections,
and our client application is not working with it. There is also a
large section that starts wtih "<wsdl: binding" which seems to be
related to the HttpGet and HttpPost sections above that is missing in
the new version's WSDL.

I'm wondering if perhaps the client application is somehow reliant on
these sections in order to function correctly. Is there a way for me to
"add" these sections back in to the web service?

Thanks in advance for any replies.
Will.

 

[m.posseth]

Hello Wil,

You should remember this rule :

Never change the signature of an already released method in a webservice

so you may add new methods , you may even change the content of the already
released methods but the Set and Get signature of these methods must always
be the same otherwise you break the compatibility to your clients .

It doesn`t mather that your current WSDL is different as before , if you add
a new method to your service it will also change , the client doesn`t even
have to be aware of this change

So ins hort you should be safe if you did not change the signature of your
previous methods

regards

Michel Posseth [MCP]

 

[rusmo1]

Thanks for your reply. I already knew not to change the method
signatures of published web services. I was able to get the WSDL's to
match by including this section in the new version's web.config:

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

This didn't solve my problem. It turns out I had a bug in the new
version of my web service, but thanks for your time.