The best way around WCF mono to .NET FaultException<T> serialization problem for basicHttpBinding RRS feed

  • Question

  • There is a known mono WCF implementation bug:

    WCF FaultException<T> basicHttpBinding Addressing Version 'AddressingNone' does not support adding WS-Addressing headers.

    When Server runs on MONO and client runs on .NET the FaultException is not properly serialized and client throws exception: System.InvalidOperationException: Addressing Version 'AddressingNone ... ' does not support adding WS-Addressing headers. That seems to be registered but not fixed yet.

    What would be the best way around this problem that allows WCF client on .NET side correctly deserializing FaultException<T> incoming object? For instance, some customization that is ignoring unexpected header element:

    <s:Header><Action s:mustUnderstand="1"

    Alternatively, may be something can be done on service side to avoid sending that message header?

    The following exception is thrown on the client side:
    System.InvalidOperationException: Addressing Version 'AddressingNone (' does not support adding WS-Addressing headers.
    Server stack trace:
       at System.ServiceModel.Channels.MessageHeaders.ReadBufferedHeader(XmlDictionaryReader reader, RecycledMessageState recycledMessageState, XmlDictionaryString[] localNames, Boolean understood)
       at System.ServiceModel.Channels.MessageHeaders.Init(MessageVersion version, XmlDictionaryReader reader, IBufferedMessageData bufferedMessageData, RecycledMessageState recycledMessageState, Boolean[] understoodHeaders, Boolean understoodHeadersModified)
       at System.ServiceModel.Channels.BufferedMessage..ctor(IBufferedMessageData messageData, RecycledMessageState recycledMessageState, Boolean[] understoodHeaders, Boolean understoodHeadersModified)
       at System.ServiceModel.Channels.TextMessageEncoderFactory.TextMessageEncoder.ReadMessage(ArraySegment`1 buffer, BufferManager bufferManager, String contentType)
       at System.ServiceModel.Channels.HttpInput.DecodeBufferedMessage(ArraySegment`1 buffer, Stream inputStream)
       at System.ServiceModel.Channels.HttpInput.ReadBufferedMessage(Stream inputStream)
       at System.ServiceModel.Channels.HttpInput.ParseIncomingMessage(HttpRequestMessage httpRequestMessage, Exception& requestException)
       at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
       at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

    • Edited by Anatoli K Monday, September 8, 2014 7:48 PM
    Monday, September 8, 2014 7:47 PM

All replies

  • Hi,

    For this situation, it probably due to the MessageVersion on your Service is not set to accept WS-Addressing. You will have to remove the Soap Header "To" and "Action" or set your MessageVersion to allow for WS-Addressing.

    If the above information doesn't help, please send the service configuration.


    Tuesday, September 9, 2014 10:43 AM
  • AFAIK they still has not finished implementing wsHttpBinding for MONO, so it is just basicHttpBinding. As it has been described above (and in the bug 19871 description), the problem does not happen if both client and server are running under Windows; or both of them are running under Linux. If the service is running under Linux and the client is .NET program under Windows, then InvalidOperationException: Addressing Version ... exception is thrown. Service configuration that demonstrates the problem is very simple:

    <endpoint binding="basicHttpBinding"contract="DemoWCF.IMyService" />


            <behavior name="MyBehavior">
              <serviceDebug includeExceptionDetailInFaults="true" />

    As for the client, if I use just basicHttpBinding, I'm getting the exception described above.
    If I use the following customBinding configuration, I'm getting the same exception.


            <binding name="MyCustomBinding">
              <textMessageEncoding messageVersion="Soap11"/>

    But if I use customBinding configuration with messageVersion attribute set to "Soap11WSAddressing10" or to "Soap11WSAddressingAugust2004" as below:

            <binding name="MyCustomBinding">
              <textMessageEncoding messageVersion="Soap11WSAddressing10"/>

    then I'm getting  ServiceModel.FaultException caught.

    But the problem is, for those configuration settings that FaultException has been deserialized into non-generic FaultException instance, but what has been actually thrown on service side is generic FaultException<ArgumentException> exception. The instance of generic FaultException<ArgumentException> class is actually caught on client side if both service and client are running under the same OS (either Windows or Linux) and that is what to be expected for any case. 

    So could you please advice what else can be changed in the client side configuration in order to make it deserializeing generic FaultException<Details> correctly?

    Thank you.

    • Edited by Anatoli K Tuesday, September 9, 2014 2:55 PM
    Tuesday, September 9, 2014 2:53 PM
  • Hi,

    This error appears to stem from the fact that basicHttpBinding is using SOAP 1.1 for the message version and no WS-Addressing, whereas netTcpBinding is using SOAP 1.2 for the message version with WS-Addressing.

    For detailed information: 

    Friday, September 12, 2014 3:12 AM