Found it. The base class must be decorated with XMLIncludeAttributes
referencing the derived classes. One of those many things that seems
like it ought to be default behaviour.... I wouldn't be so frustrated
even autocompleting these values for me.
Quote:
I'm getting acquainted with the whole XML/XSD thing, and I've run into
a wall. I have a tree of objects that I deserialize from XML for
configuration reasons. I have generated XSD from the classes for this
tree. I have made an XML file that validates against that XSD.
However, when I try to deserialize from the XML file, I get complaints
that
>
System.InvalidOperationException was unhandled
Message="There is an error in XML document (11, 6)."
>
Now, this is using a validating reader based on XSD that was generated
from the very classes I'm trying to deserialize. The focus of the
problem is this: I use a lot of collections where the collection
contains the base, abstract class and the types within the collection
are of numerous derived classes. As a result, the names of the
XmlArray elements are the name of the abstract class, with the names of
the derived classes held in the xsi:type attribute. It seems that when
the XML Deserializer runs into these XSI:type attributes (the first of
which is at 11,6), it throws a hissy-fit.
>
Thus, the problem:
>
<MergeModules>
<MergeModule xsi:type ="MergeFiles"></MergeModule >
</MergeModules>
>
where MergeModule is my abstract class, "MergeFiles" is my derived
class, and both MergeModules and MergeFiles are valid XSD types that
were generated from the aforementioned assembly classes.
>
What gives? Is there some trick to cajole the XML Deserializer to use
my schema to help it figure out which XSD type corresponds to which
DotNet type? Or do I have to go through the rigamarole of manually
listing every single type that could exist in every single array that
holds a MergeModule? Some of the busiwork of that can be used with
XmlAttributeOverrides, but then I'm pretty sure that XSD.EXE will not
be aware of the procedurally-added attributes, and thus I'd have to go
through a whole different rigamarole with setting up an XSD
schema-exporter within my app.
>
Do I just have to suck it up and accept it that the statement (from the
XSD.EXE documentation):
"""
Classes to XSD
Generates an XML schema from a type or types in a runtime assembly
file. The generated schema defines the XML format used by
System.XML.Serialization.XMLSerializer.
"""
is false? Or is there some workaround, maybe by some bizarre
application of the SOAP deserializer?
