none
Deserializing exception on void web service operation

    Frage

  • Hi,
    I'm trying to call a method on a web service. I've consumed the WSDL by using the "Add service reference" in VS 2010.
    The method I'm calling is not supposed to return anything, it is void.
    The response I get is this:
    <?xml
      version="1.0"
      encoding="utf-8"
      ?>
    <soapenv:Envelope
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <soapenv:Body>
         <monitorStopResponse/>
       </soapenv:Body>
    </soapenv:Envelope>
    
     
    The exception I get from the VS debugger is the following:
    "Error in deserializing body of reply message for operation 'MonitorStop'. End element 'Body' from namespace 'http://schemas.xmlsoap.org/soap/envelope/' expected. Found element 'monitorStopResponse' from namespace ''. Line 1, position 250."
    Stack trace:
    at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader reader, String res, String arg1, String arg2, String arg3)
    at System.Xml.XmlExceptionHelper.ThrowEndElementExpected(XmlDictionaryReader reader, String localName, String ns)
    at System.Xml.XmlBaseReader.ReadEndElement()
    at System.ServiceModel.Channels.Message.ReadFromBodyContentsToEnd(XmlDictionaryReader reader, EnvelopeVersion envelopeVersion)
    at System.ServiceModel.Channels.Message.ReadFromBodyContentsToEnd(XmlDictionaryReader reader)
    at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeBodyContents(Message message, Object[] parameters, Boolean isRequest)
    at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeReply(Message message, Object[] parameters)
    So it seems to me that the deserializer do not expect the <monitorStopResponse/>
    Just for info; when calling a method on the service which actually returns something, everything works fine.
    Thanks in advance, Nicklas
    Dienstag, 10. Mai 2011 08:57

Alle Antworten

  • even a void web service returns an empty response, which is the one you see.

    to understand why this response is wrong we would need to see the wsdl. one option is that the monitorStopResponse is expected by wcf to be under some namespace and not the empty one as here. wcf seems to also allow it not to be present at all. while you could fix all that on the client side using message inspectores, I suggest to find the root cause of this together with the server author. Is that you? Is th server written with wcf?


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Dienstag, 10. Mai 2011 09:29
  • Thanks for the quick reply.

    At the given time I'm not allowed to show the WSDL.

    I have to solve this on the client side as I'm not in position of changing the server.

    The server is written in Java.

     

    Can you tell me how I should use the message inspectors?

     

    Thanks, Nicklas

    Dienstag, 10. Mai 2011 09:45
  • The option of a message Inspector would work indeed. You could detect that the body contains data before the message is being deserialized and then just remove the data in the messagebody

    Another option is to change the return type of the method from void to Message in the Generated proxy, that way it will accept any return value, but you can ignore it safely.

    We've had similar issues while connecting to earlier SAP versions, and I remember that they needed to upgrade the Java SOAP library to a newer version in order to solve the issue on the server side.

    Dienstag, 10. Mai 2011 16:03
  • Nicklas,

    We have a sample that shows how to implement and configure a message inspector for your service/client. Please take a look at it here: http://msdn.microsoft.com/en-us/library/aa717047.aspx. Here are some other places to find information on message inspectors:

    http://weblogs.asp.net/paolopia/archive/2007/08/23/writing-a-wcf-message-inspector.aspx

    http://blogs.msdn.com/b/endpoint/archive/2011/04/23/wcf-extensibility-message-inspectors.aspx

    I hope this helps,

    Michael Green
    WCF Documentation Team

    Dienstag, 10. Mai 2011 19:06
  • Thanks for the links to message inspector implementations.
    I've been trying to write some code to remove the body from the message (just to get started), but are constantly getting "This message cannot support the operation because it has been copied/written".
    Here's what I have so far:
     
    public void AfterReceiveReply(ref Message reply, object correlationState)
            {
                MessageBuffer buffer = reply.CreateBufferedCopy(Int32.MaxValue);
                Message originalMessage = buffer.CreateMessage();
                StringBuilder sb = new StringBuilder();
                XmlWriter writer = XmlWriter.Create(sb);
     
                originalMessage.WriteBody(writer);
                reply = originalMessage;
                buffer.Close();
            }
    When the operation is called on the web service I get: "This message cannot support the operation because it has been written." on the following line:
    _service.MonitorStop();
    
    Any ideas?
    Mittwoch, 11. Mai 2011 11:09
  • The option to change return type seems quite simply compared to message inspectors - but how can I change the return type and will it be overriden if I update the proxy in case of a web service update?
    Mittwoch, 11. Mai 2011 11:11
  • Open the Reference.cs file and change the content there. And yes, this will be overwritten upon an update of the service reference.
    Mittwoch, 11. Mai 2011 11:23
  • Althou it has it disadvantages if I update the service reference I will use the option of manually editing the proxy.

    This seems to be the best way to get it to work

    A side note: Isn't this a bug in the WCF? The generated methods in the proxy all has a return type, but when the web service operation is actually returning something, as described in my first post, an execption is fired?

    Thanks for all the input,

    Nicklas

    Mittwoch, 11. Mai 2011 11:49
  • Well, actually it din't solve the problem. I've changed all the return type to void in the Reference.cs file, but still the method call fails with the above exception.
    Donnerstag, 12. Mai 2011 12:40