Add Service Reference: Ordering of Serialization Fields

Question

I'm writing a C# web service client in Visual Studio 2008 with a Java web service endpoint. I have no control over the endpoint and the SOAP messages that it sends back.

I created an auto-generated proxy client from the web service WSDL using the "Add Service Reference" option in Visual Studio. When I send my request I get a valid SOAP message back, which contains something like this:

<java:a_field xmlns:java="java:com.whatever">Value1</java:a_field>
<java:different_field xmlns:java="java:com.whatever">Value2</java:different_field>

However, it does not actually parse those two values, and all of the values after that are null. After debugging, I found that this code in the auto-generated Reference.cs was the problem:

[System.Xml.Serialization.XmlElementAttribute(IsNullable=true, Order=30)]
public string different_field {
    get {
        return this.different_fieldField;
    }
    set {
        this.different_fieldField = value;
        this.RaisePropertyChanged("different_field");
    }
}

/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(IsNullable=true, Order=31)]
public string a_field {
    get {
        return this.a_fieldField;
    }
    set {
        this.a_fieldField = value;
        this.RaisePropertyChanged("a_field");
    }
}

These two fields are out of order, so it doesn't serialize them properly, and the rest of the fields are not serialized at all. The WSDL itself declares the fields in the same order that the proxy class is expecting them in, it's just the actual response that changes the order. I can work around this by manually swapping the two Order= values, but that would be a huge pain to maintain given that the WSDLs change frequently and there are 100s of fields that need to be checked for this kind of error. Is there any better way for me to be able to ignore this ordering mismatch and still use the auto-generated web service proxy?

Answer 1

Having dealt with something similar, and knowing that it's a giant pain, I would suggest creating your own "fake" WSDL that reflects what is actually returned from the web service instead of what is specified. The issue appears to relate more to an inaccurate XSD that is part of the WSDL. It seems that some of the Java web service frameworks do not follow the order (or other specifications) strictly by default, and your third-party web service provider may not have the knowledge, resources, or motivation to fix the problem.

It is better still, as a matter of best practice, not to import the WSDL at all as a service reference, instead creating the interfaces and service proxies by hand and the configuration either manually or with the WCF Service Configuration Editor. There are a number of resources on how to do this -- Google is your friend.