By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,408 Members | 1,796 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,408 IT Pros & Developers. It's quick & easy.

Problems replacing SoapToolkit with .NET WebMethods (Server Side)

P: n/a
Hi - we are MSDN Enterprise subscribers, our no-spam address is
mu****@computershare.com

We are currently trying to replace a SoapToolkit web-service with a .NET
WebMethod implementation, but can't seem to get the WSDL to line up properly.

I consulted the migration document:
http://msdn.microsoft.com/library/de...oapwebserv.asp

I then used wsdl.exe to create an abstract class definition for the new
service. The class and first method are as follows:

[System.Web.Services.WebServiceBindingAttribute(Nam e="PAFServerSoapBinding",
Namespace="http://tempuri.org/wsdl/")]
public abstract class AbstractPAFServer : System.Web.Services.WebService {

[System.Web.Services.WebMethodAttribute()]

[System.Web.Services.Protocols.SoapRpcMethodAttribu te("http://tempuri.org/action/PAFServer.GetAddressList",
RequestNamespace="http://tempuri.org/message/",
ResponseNamespace="http://tempuri.org/message/")]
[return: System.Xml.Serialization.SoapElementAttribute("Res ult")]
public abstract string GetAddressList(string PostCode, string
StreetName, string StreetNo, bool ExactMatch, out int nItems);

I then created an implementation which derives from this abstract class. All
is fine so far, but the resulting asmx?WSDL does not match the original WSDL.
For instance, the message names:

-------- OLD SOAP TOOLKIT WSDL -------------

- <message name="PAFServer.GetAddressList">
<part name="PostCode" type="xsd:string" />
<part name="StreetName" type="xsd:string" />
<part name="StreetNo" type="xsd:string" />
<part name="ExactMatch" type="xsd:boolean" />
</message>
- <message name="PAFServer.GetAddressListResponse">
<part name="Result" type="xsd:string" />
<part name="nItems" type="xsd:int" />
</message>

---------- NEW ASMX?WSDL --------------

- <message name="GetAddressListSoapIn">
<part name="PostCode" type="s:string" />
<part name="StreetName" type="s:string" />
<part name="StreetNo" type="s:string" />
<part name="ExactMatch" type="s:boolean" />
</message>
- <message name="GetAddressListSoapOut">
<part name="Result" type="s:string" />
<part name="nItems" type="s:int" />
</message>

Now, I read some articles on overriding these message names, for instance:
http://msdn.microsoft.com/library/de...insidewsdl.asp
which describes the use of various attributes to modify the resulting WSDL.
Nothing seems to be able to stop .NET appending "SoapIn" and "SoapOut" to the
message names.

Is there a way of getting the new WSDL to match the old WSDL, or are we
going to have to give up and distribute new client side proxies that match
the .NET asmx WSDL?



Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Hello,

We can only control the Message's name like "GetAddressList". For "SoapIn"
and 'SoapOut", they are generated by the .NET Framework based on the name
of the WebMethod, the protocol used, and the direction of the message. I
think you have to distribute the new client WSDL.

Regards,

Luke

Nov 12 '05 #2

P: n/a
False alarm folks. It turns out that when you use RPC a lot of the WSDL is
effectively ignored. The existing client has no problems accessing the site
with the asmx code generated by wsdl.exe

"[MSFT]" wrote:
Hello,

We can only control the Message's name like "GetAddressList". For "SoapIn"
and 'SoapOut", they are generated by the .NET Framework based on the name
of the WebMethod, the protocol used, and the direction of the message. I
think you have to distribute the new client WSDL.

Regards,

Luke

Nov 12 '05 #3

P: n/a
Yes, you are right at this.

Luke

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.