3

We are using XSD.EXE to generate runtime classes from an XSD schema for XML serialization. The schema is large and contains many complex types and choice elements. As described in http://msdn.microsoft.com/en-us/magazine/cc164135.aspx, choice elements generate two fields: an Item field to hold the value and an ItemChoiceType field which holds a generated enum defining which named element is in the Item field.

XSD creates a unique enum for each of these element name fields named ItemChoiceTypeXX, where XX is an integer. XSD creates as many of these ItemChoiceTypes as it needs and names them with incremented number.

So, a small piece of my schema looks like:

<xsd:choice>
  <xsd:element ref = "Sequence"/>
  <xsd:element ref = "HandshakeId"/>
</xsd:choice>

and I can code to it like using the generated classes like:

job.Item = "123";        
job.ItemElementName = ItemChoiceType26.Sequence;

The problem is that in the originally generated classes, the ItemChoiceType for this element was ItemChoiceType26. After updating the schema and regenerating the classes, the name is now ItemChoiceType27.

My question is how do I manage this as the schema is updated and revised over time? I don't control the XSD schema, it is provided by a vendor. However, I do have to update my code to match changes they make. This seems like I'm facing a maintenance nightmare over time and would like any suggestions to better manage this.

Michael Levy
  • 13,097
  • 15
  • 66
  • 100

1 Answers1

0

I think the correct answer to this is to instead of ref use name attributes.

<xsd:choice>
  <xsd:element name="Sequence"/>
  <xsd:element name="HandshakeId"/>
</xsd:choice>

At least this worked for me.

Spiralis
  • 3,232
  • 2
  • 39
  • 53