Hi,
I have actually found 2 ways to do this. One uses the XmlInclude
attribute in the base class A, specifying the valid derived types to
deserialize from the stream, and one uses one of the 8 XmlSerializer
ctor's to specify base class A and derived class B relationships.
However, XmlInclude only works at compile-time, and I would like to
support serialisation for future derived classes C in other modules.
So in this case, this option is not practical.
The second option works if your data (de)serialisati on is starting in
class Z instances that have the base A or derived instances B,C
directly as members. But if these class Z instances themseves are
already tagged with the [Serializable] attribute and are serialized
somewhere else (possibly in a deep hierarchy), you end up with a bit
of a nasty problem:
It forces you to implement the IXmlSerializabl e interface on a level
(class Z) which would otherwise serialize just fine, except for those
data members that derive from the base class A. You have to implement
customized serialisation methods at that level because you need to be
able to construct the serializer for that member (one of the derived
instances B,C of A). Things can get even more nasty when these
instances are kept in a container structure like e.g. [XmlArray] where
it is actually the tagged container that serialises it's members. So,
in this special case, you end up re-implementing custom list
(de)serialisati on for a container structure that otherwise already
worked fine!
Possibly I missed another option? What would be the preferred way to
deal with this situation correctly?
Cheers!
a0a
I have actually found 2 ways to do this. One uses the XmlInclude
attribute in the base class A, specifying the valid derived types to
deserialize from the stream, and one uses one of the 8 XmlSerializer
ctor's to specify base class A and derived class B relationships.
However, XmlInclude only works at compile-time, and I would like to
support serialisation for future derived classes C in other modules.
So in this case, this option is not practical.
The second option works if your data (de)serialisati on is starting in
class Z instances that have the base A or derived instances B,C
directly as members. But if these class Z instances themseves are
already tagged with the [Serializable] attribute and are serialized
somewhere else (possibly in a deep hierarchy), you end up with a bit
of a nasty problem:
It forces you to implement the IXmlSerializabl e interface on a level
(class Z) which would otherwise serialize just fine, except for those
data members that derive from the base class A. You have to implement
customized serialisation methods at that level because you need to be
able to construct the serializer for that member (one of the derived
instances B,C of A). Things can get even more nasty when these
instances are kept in a container structure like e.g. [XmlArray] where
it is actually the tagged container that serialises it's members. So,
in this special case, you end up re-implementing custom list
(de)serialisati on for a container structure that otherwise already
worked fine!
Possibly I missed another option? What would be the preferred way to
deal with this situation correctly?
Cheers!
a0a