Web service client receiving generic FaultException rather than FaultException<T>

I am connecting to a Java Axis2 web service using a .NET web service client. The client itself targets the .NET 3.5 framework. The application that wraps the client DLL is 2.0. I'm not sure if that has any bearing.

I have been given the WSDL and XSDs by email. From those I have built my proxy class using svcutil. Although I am able to successfully send messages, I am unable to pick up the correct faults when something goes wrong. In the example below, errors are always being picked up by the generic FaultException.

catch (FaultException<InvoiceErrorType> fex)
{
    OnLog(enLogLevel.ERROR, fex.Detail.ErrorDescription);
}
catch (FaultException gfex)
{
    OnLog(enLogLevel.ERROR, gfex.Message);
}

The proxy client appears to have the appropriate attributes for the FaultContract:

// CODEGEN: Generating message contract since the operation SendInvoiceProvider_Prod is neither RPC nor document wrapped.
[OperationContractAttribute(Action = "https://private/SendInvoiceProvider", ReplyAction = "*")]
[FaultContractAttribute(typeof(InvoiceErrorType), Action = "https://private/Send开发者_StackOverflowInvoiceProvider", Name = "InvoiceError", Namespace = "urn:company:schema:entities:base")]
[XmlSerializerFormatAttribute(SupportFaults = true)]
[ServiceKnownTypeAttribute(typeof(ItemDetail))]
[ServiceKnownTypeAttribute(typeof(Supplier))]
OutboundComponent.SendInvoiceProviderResponse SendInvoiceProvider_Prod(OutboundComponent.SendInvoiceProvider_Request request);

I have enabled tracing and I can see the content of the fault coming back, but .NET is not recognizing it as an InvoiceError. The SOAP fault in full is:

<soapenv:Fault>
    <faultcode xmlns="">soapenv:Client</faultcode>
    <faultstring xmlns="">Message found to be invalid</faultstring>
    <faultactor xmlns="">urn:SendInvoiceProvider</faultactor>
    <detail xmlns="">
        <InvoiceError xmlns="urn:company:schema:entities:common:invoiceerror:v01">
                <ErrorID>100040</ErrorID>
                <ErrorType>UNEXPECTED</ErrorType>
                <ErrorDescription>&lt;![CDATA[&lt;error xmlns="urn:company:schema:errordetail:v01"&gt;&lt;errorCode&gt;1000&lt;/errorCode&gt;&lt;highestSeverity&gt;8&lt;/highestSeverity&gt;&lt;errorDetails count="1"&gt;&lt;errorDetail&gt;&lt;errorType&gt;1&lt;/errorType&gt;&lt;errorSeverity&gt;8&lt;/errorSeverity&gt;&lt;errorDescription&gt;cvc-complex-type.2.4.a: Invalid content was found starting with element 'CompanyName'. One of '{"urn:company:schema:sendinvoice:rq:v01":RoleType}' is expected.&lt;/errorDescription&gt;&lt;errorNamespace&gt;urn:company:schema:sendinvoice:rq:v01&lt;/errorNamespace&gt;&lt;errorNode&gt;CompanyName&lt;/errorNode&gt;&lt;errorLine&gt;1&lt;/errorLine&gt;&lt;errorColumn&gt;2556&lt;/errorColumn&gt;&lt;errorXPath/&gt;&lt;errorSource/&gt;&lt;/errorDetail&gt;&lt;/errorDetails&gt;&lt;/error&gt;]]&gt;</ErrorDescription>
                <TimeStamp>2010-05-04T21:12:10Z</TimeStamp>
        </InvoiceError>
    </detail>
</soapenv:Fault>

I have noticed the namespace defined on the error:

<InvoiceError xmlns="urn:company:schema:entities:common:invoiceerror:v01">

This is nowhere to be seen in the generated proxy class, nor in the WSDLs. The interface WSDL defines the error schema namespace as such:

<xs:import namespace="urn:company:schema:entities:base" schemaLocation="InvoiceError.xsd"/>

Could this be the reason why the .NET client is not able to parse the typed Fault Exception correctly?

I have no control over the web service itself. I see no reason why .NET can't talk to a Java Axis2 web service. This user had a similar issue, but the reason for his problem cannot be the same as mine, since I can see the fault detail in the trace: Does WCF FaultException<T> support interop with a Java web service Fault

Any help would be gratefully received.

The namespace given in the WSDL for the custom Fault type did not match the fault namespace that was being raised. As a result, the .NET client was unable to deserialize the fault correctly.

In other words, the third party company needs to either change the WSDL or change the namespace on the error that is being raised.

The most useful tool to help you get to the bottom of such problems is to setup a trace: http://msdn.microsoft.com/en-us/library/ms732023.aspx.