C# WCF Service Reference exposes concrete class instead of inherited abstract class when abstract class is referenced

Question

I am generating a C# service reference using Visual Studio 2010 from my wsdl. (Simplified example, please excuse any syntax errors):

<xs:complexType name="Constraints">
  <xs:sequence>
    <xs:element minOccurs="1" maxOccurs="unbounded" ref="p:Constraint" />
  </xs:sequence>
</xs:complexType>

<xs:element name="Constraint" type="p:ConstraintType" />

<xs:complexType abstract="true" name="ConstraintType />

<xs:complexType name="RelConstraint" >
  <xs:complexContent>
    <xs:extension base="p:ConstraintType">
     ...
    </xs:extension>
  <xs:complexContent>
</xs:complexType>

<xs:complexType name="Logic" abstract="true">
  <xs:complexContent>
    <xs:extension base="p:ConstraintType">
     ...
    </xs:extension>
  <xs:complexContent>
</xs:complexType>  

<xs:complexType name="AndLogic" >
  <xs:complexContent>
    <xs:extension base="p:Logic">
     ...
    </xs:extension>
  <xs:complexContent>
</xs:complexType>

The element of Constraints is .Item not .Constraint (which is fine and I know that this happens with abstraction).

However, Constraints.Item type is RelConstraint not ConstraintType so it doesn't recognize AndLogic as a possible type.

So it seems that if one concrete type is abstracted one level and another is abstracted two levels the service reference sets any reference to the class only abstracted one level.

(E.g. ConcreteClassA extends AbstractClassC, ConcreteClassB extends AbstractClassB which extends AbstractClassC,

ConcreteClassX has element AbstractClassC, which should be of that type. However, the element is of type ConcreteClassA)

Is there a work around?

This relates to WHY doesn't WCF 'properly' consume/expose abstract types when hosted as a web service

Answer 1

So my first idea that almost worked was removing the abstract="true" from the element declaration but leaving it on the type declaration. Here's the declaration of both the element and type before removing anything:

<xs:element abstract="true" name="Logic" substitutionGroup="p:Constraint" type="p:LogicType" />

<xs:complexType name="LogicType" abstract="true">
  <xs:complexContent>
    <xs:extension base="p:ConstraintType">
      ...
    </xs:extension>
  <xs:complexContent>
</xs:complexType>

Visual studio actually generated the code correctly! And from what I could find, removing abstract from the element but not the type was not an incorrect implementation of an abstract object. (However, I'm still weary about this point).

So I wrote up some test xml and sent it to my c# program from my server. And of course... it wouldn't Serialize the objects correctly (they were all set to null).

So I finally looked directly at the Reference.cs file to see if I could figure out the problem.

[System.Xml.Serialization.XmlElementAttribute("Logic", typeof(LogicType), Order = 0)]
[System.Xml.Serialization.XmlElementAttribute("RelConstraint", typeof(RelConstraintType), Order = 0)]
public ConstraintComponentType Item

It looked correct but I decided to add XmlElementAttribute declarations for AndLogic and my other logic types to see what happened. And it finally serialized the test data correctly!

[System.Xml.Serialization.XmlElementAttribute("And", typeof(AndType), Order = 0)]
[System.Xml.Serialization.XmlElementAttribute("Logic", typeof(LogicType), Order = 0)]
[System.Xml.Serialization.XmlElementAttribute("RelConstraint", typeof(RelConstraintType), Order = 0)]
public ConstraintComponentType Item

So what I ended up doing was putting abstract="true" back on my elements to make my schema correct, and then going in and doing the aforementioned step along with changing anywhere it incorrectly generated the type, e.g.

[System.Xml.Serialization.XmlElementAttribute("Logic", typeof(LogicType), Order = 0)]
[System.Xml.Serialization.XmlElementAttribute("RelConstraint", typeof(RelConstraintType), Order = 0)]
public RelConstraintType Item

So the only problem is that if you want to regenerate the service reference, you have to go back through and manually edit the Reference.cs file again.