M
Martin Z
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?
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?