Question

I am working with an external vendor’s web service that appears to be implemented in Java (I believe Apache Axis), and I’m consuming it with a WCF client. Several of the operations require input parameters of type enumeration. The problem is that they only want the enums passed in certain cases. The elements are not marked as nillable in the WSDL. Since they are enums,though, my WCF client will always pass the default value even if not specified. This behavior is causing an internal error in their service.

Any thoughts on how to address this issue? Preferably, it would be solution that would not require manual modification of the proxy, as this might result in confusion if another developer were to generate it independently in the future.

The particular element is specified as follows in the WSDL

<xs:complexType name="complexTypeName">
<xs:sequence>
    <!-- More Stuff Here-->
    <xs:element minOccurs="0" name="parameterName" type="tns:parameterName" />
    <!-- More Stuff Here-->
</xs:sequence>
</xs:complexType>

<!-- . . . -->

<xs:simpleType name="parameterName">
  <xs:restriction base="xs:string">
    <xs:enumeration value="ONLY_AVAILABLE_VALUE" />
  </xs:restriction>
</xs:simpleType>

Svcutil translates this as

[System.CodeDom.Compiler.GeneratedCodeAttribute("svcutil", "4.0.30319.1")]
[System.SerializableAttribute()]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://vendorwebservicenamespace.com/")]
public enum parameterName
{   
    /// <remarks/>
    ONLY_AVAILABLE_VALUE,
}

EDIT: After a bit more research, it looks like svcutil should normally generate optional parameters (minOccurs=0) with an additional bool fieldNameSpecified parameter, allowing the caller to indicate whether or not the field should be serialized (this is documented here, here, and here).

In this case, however, the parameter is referenced as follows:

[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://vendorservicenamespace.com/", Order=23)]
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public Namespace.parameterName parameterName;

When I try to manually add the appropriate fieldNameSpecified method, it doesn’t seem to have any affect on the serialization (i.e., the parameter is still presents in the soap message).

At this point, I am wondering

1. Why isn’t svcutil including the fieldNameSpecified parameters?
2. Why doesn’t adding the parameter manually seem to work?
3. Are there any other workarounds available for this issue?

EDIT: After yet more research, I’ve determined that part of the issue is the way in which the WSDL is written. The Vendor’s WSDL does not conform to the Schema Reference for the DataContractSerializer. Because of this, svcutil is failing back to the XmlSerializer.

The problem is that it is still generating the message contracts for the methods, but not the data contracts. This appears to result in a problem for any types that are not nullable by default, in that they cannot be excluded from the message (can anyone verify this?). Whatever reason the parameterNameSpecified method for the XmlSerializer appears to be ignored when a parameter is flagged with the MessageBodyMemberAttribute (not sure why?)

The only way I have been able to get around this behavior is by using the /wrapped option with svcutil. This results in message contracts being separated from the actual seralized parameters themselves. In this case, svcutil does generate the parameterNameSpecified methods, and the XmlSerializer conforms to them.

Answer 1

After researching the issue, the only solution that I’ve been able to find is to generate the proxy using the /wrapped option on svcutil. As referenced above in the question, this adds an additional layer of abstraction and allows the message contracts to exist a layer above the parameters. In this case the XmlSerializer does generate the fieldNameSpecified properties and conforms to them.