locked
Possible SOAP version mismatch

    Question

  •  

    Dear All,

     

    I'm facing this problem,

     

    when i'm trying to connect to a webservice throw my .net application it goes fine, but when invoke the property URL to give the url of webservice it show me this message :

    Possible SOAP version mismatch: Envelope namespace http://schemas.xmlsoap.org/wsdl/ was unexpected. Expecting http://schemas.xmlsoap.org/soap/envelope/.

     

    notice that if i write the url by choosing properties of web reference it goes fine. But i need to invoke the property since the URL is subject to change in future so i'll let user fill it if needed.

     

     

    regards,

     

    Friday, December 07, 2007 4:00 AM

Answers

  • The problem is that you are setting the URL property of the webservice to the WSDL url.  You need to set the URL of the webservice instance to the location of the webservice itself, which is something that is contained within the WSDL.  To find this URL, open the WSDL document in a text editor and look for the "location" attribute of the <soap:address> element.  You can and should still use the WSDL url for graphical tools within visual studio, but it's important to make the distinction at run-time.
    Tuesday, July 22, 2008 5:50 PM

All replies

  • If I understand you correctly, your .net application was able to access your web service. You then changed your .net application to set the Url property at run-time. When this happened, you got an error. If I have misunderstood you, please let me know.

     

    The error you posted makes no sense.  It sounds like the XML being sent to the server has become something like:

     

    Code Block

    <soap: Envelope xmlns: soap="http://schemas.xmlsoap.org/wsdl/">

    </soap: Envelope>

     

     

    I can't think of any way for this to happen, and it definitely wouldn't happen because you set the Url property. Could you please post some code to show what you're doing?

     

    Also, try commenting out just the line of code that sets the Url property and see if the problem still occurs.

    Friday, December 07, 2007 3:37 PM
    Moderator
  •  

    Also, try commenting out just the line of code that sets the Url property and see if the problem still occurs.

     

    when i comment this line the error doesn't exist that what i mentioned in the first post. I need to set the URL property during runtime. so how to reslove this error ?

    Friday, December 07, 2007 5:09 PM
  • As I said earlier, please post some code showing what you're doing.

     

    This is obviously not as simple as "set Url property" == "bad XML", or nobody would ever have been able to use the Url property. There must be something more to it, but I can't see what that could be, unless you post the code that causes the problem.

     

    Saturday, December 08, 2007 2:57 AM
    Moderator
  • smsService.Url="mywebservic.com\ssmss.cgi\wsdl\smsservice";

    Saturday, December 08, 2007 11:51 AM
  •  SomeOneRiy wrote:

    smsService.Url="mywebservic.com\ssmss.cgi\wsdl\smsservice";

     

    That does not appear to be a proper URL. Is that the literal string you're using? Not one starting with "http://"?

     

    Also, you should take a look at the network traffic both sending and receiving. I wonder if the problem with the soap envelope might not be with the envelope coming from the server rather than the envelope you're sending to the server. Use a tool like Microsoft Network Monitor or tcptrace from http://www.pocketsoap.com.

    Sunday, December 09, 2007 5:45 PM
    Moderator
  • The problem is that you are setting the URL property of the webservice to the WSDL url.  You need to set the URL of the webservice instance to the location of the webservice itself, which is something that is contained within the WSDL.  To find this URL, open the WSDL document in a text editor and look for the "location" attribute of the <soap:address> element.  You can and should still use the WSDL url for graphical tools within visual studio, but it's important to make the distinction at run-time.
    Tuesday, July 22, 2008 5:50 PM