XML Serialization and Inherited Types?

Problem Solved! OK, so I finally got there (admittedly with a lot of help from here! ).

So summarise: Goals: I didn't want to go down the XmlInclude route due to the maintenence headache. Once a solution was found, I wanted it to be quick to implement in other applications. Collections of Abstract types may be used, as well as individual abstract properties.

I didn't really want to bother with having to do "special" things in the concrete classes. Identified Issues/Points to Note: XmlSerializer does some pretty cool reflection, but it is very limited when it comes to abstract types (i.e. It will only work with instances of the abstract type itself, not subclasses).

The Xml attribute decorators define how the XmlSerializer treats the properties its finds. The physical type can also be specified, but this creates a tight coupling between the class and the serializer (not good). We can implement our own XmlSerializer by creating a class that implements IXmlSerializable .

The Solution I created a generic class, in which you specify the generic type as the abstract type you will be working with. This gives the class the ability to "translate" between the abstract type and the concrete type since we can hard-code the casting (i.e. We can get more info than the XmlSerializer can).

I then implemented the IXmlSerializable interface, this is pretty straight forward, but when serializing we need to ensure we write the type of the concrete class to the XML, so we can cast it back when de-serializing. It is also important to note it must be fully qualified as the assemblies that the two classes are in are likely to differ. There is of course a little type checking and stuff that needs to happen here.

Since the XmlSerializer cannot cast, we need to provide the code to do that, so the implicit operator is then overloaded (I never even knew you could do this! ). The code for the AbstractXmlSerializer is this: using System; using System.Collections.

Generic; using System. Text; using System.Xml. Serialization; namespace Utility.

Xml { public class AbstractXmlSerializer : IXmlSerializable { // Override the Implicit Conversions Since the XmlSerializer // Casts to/from the required types implicitly. Public static implicit operator AbstractType(AbstractXmlSerializer o) { return o. Data; } public static implicit operator AbstractXmlSerializer(AbstractType o) { return o == null?

Null : new AbstractXmlSerializer(o); } private AbstractType _data; /// /// Concrete Data to be stored/is stored as XML. /// public AbstractType Data { get { return _data; } set { _data = value; } } /// /// **DO NOT USE** This is only added to enable XML Serialization. /// /// DO NOT USE THIS CONSTRUCTOR public AbstractXmlSerializer() { // Default Ctor (Required for Xml Serialization - DO NOT USE) } /// /// Initialises the Serializer to work with the given data.

/// /// Concrete Object of the AbstractType Specified. Public AbstractXmlSerializer(AbstractType data) { _data = data; } #region IXmlSerializable Members public System.Xml.Schema. XmlSchema GetSchema() { return null; // this is fine as schema is unknown.

} public void ReadXml(System.Xml. XmlReader reader) { // Cast the Data back from the Abstract Type. String typeAttrib = reader.

GetAttribute("type"); // Ensure the Type was Specified if (typeAttrib == null) throw new ArgumentNullException("Unable to Read Xml Data for Abstract Type '" + typeof(AbstractType). Name + "' because no 'type' attribute was specified in the XML. "); Type type = Type.

GetType(typeAttrib); // Check the Type is Found. If (type == null) throw new InvalidCastException("Unable to Read Xml Data for Abstract Type '" + typeof(AbstractType). Name + "' because the type specified in the XML was not found."); // Check the Type is a Subclass of the AbstractType.

If (!type. IsSubclassOf(typeof(AbstractType))) throw new InvalidCastException("Unable to Read Xml Data for Abstract Type '" + typeof(AbstractType). Name + "' because the Type specified in the XML differs ('" + type.

Name + "'). "); // Read the Data, Deserializing based on the (now known) concrete type.Reader. ReadStartElement(); this.

Data = (AbstractType)new XmlSerializer(type). Deserialize(reader); reader.ReadEndElement(); } public void WriteXml(System.Xml. XmlWriter writer) { // Write the Type Name to the XML Element as an Attrib and Serialize Type type = _data.GetType(); // BugFix: Assembly must be FQN since Types can/are external to current.

Writer. WriteAttributeString("type", type. AssemblyQualifiedName); new XmlSerializer(type).

Serialize(writer, _data); } #endregion } } So, from there, how do we tell the XmlSerializer to work with our serializer rather than the default? We must pass our type within the Xml attributes type property, for example: XmlRoot("ClassWithAbstractCollection") public class ClassWithAbstractCollection { private List _list; XmlArray("ListItems") XmlArrayItem("ListItem", Type = typeof(AbstractXmlSerializer)) public List List { get { return _list; } set { _list = value; } } private AbstractType _prop; XmlElement("MyProperty", Type=typeof(AbstractXmlSerializer)) public AbstractType MyProperty { get { return _prop; } set { _prop = value; } } public ClassWithAbstractCollection() { _list = new List(); } } Here you can see, we have a collection and a single property being exposed, and all we need to do is add the type named parameter to the Xml declaration, easy! :D NOTE: If you use this code, I would really appreciate a shout-out.

It will also help drive more people to the community :) Now, but unsure as to what to do with answers here since they all had their pro's and con's. I'll upmod those that I feel were useful (no offence to those that weren't) and close this off once I have the rep :) Interesting problem and good fun to solve! :).

I ran into this problem myself some time ago. Personally, I ended up abandoning XmlSerializer and using the IXmlSerializable interface directly, since all my classes needed to implement it anyway. Otherwise, the solutions are quite similar.

Good write-up though :) – Thorarin Jun 12 '09 at 8:26 Great work thanks Rob – Kane Feb 16 '10 at 14:00 We use XML_ properties where we convert the list to Arrays :) – Arcturus Mar 3 '10 at 10:13 why is it necessary to declare the default constructor, if you're not allowed to use it? – Frederik Gheysels Apr 22 '10 at 7:22 Because a parameterless constructor is needed in order to dynamically instantiate the class. – Silas Hansen May 19 '10 at 13:40.

One thing to look at is the fact that in the XmlSerialiser constructor you can pass an array of types that the serialiser might be having difficulty resolving. I've had to use that quite a few times where a collection or complex set of datastructures needed to be serialised and those types lived in different assemblies etc. XmlSerialiser Constructor with extraTypes param EDIT: I would add that this approach has the benefit over XmlInclude attributes etc that you can work out a way of discovering and compiling a list of your possible concrete types at runtime and stuff them in.

This is what I'm trying to do, but it is not easy as I was thinking: stackoverflow. Com/questions/3897818/… – Luca Piccioni Nov 4 '10 at 20:28.

Seriously, an extensible framework of POCOs will never serialize to XML reliably. I say this because I can guarantee someone will come along, extend your class, and botch it up. You should look into using XAML for serializing your object graphs.It is designed to do this, whereas XML serialization isn't.

The Xaml serializer and deserializer handles generics without a problem, collections of base classes and interfaces as well (as long as the collections themselves implement IList or IDictionary). There are some caveats, such as marking your read only collection properties with the DesignerSerializationAttribute, but reworking your code to handle these corner cases isn't that hard. If you're interested, I've got a couple of posts detailing the ins and outs of xaml serialization here.

NOT BLARG SPAM! Seriously, even Microsoft engineers use these posts as references. I'm so proud...

I've done things similar to this. What I normally do is make sure all the XML serialization attributes are on the concrete class, and just have the properties on that class call through to the base classes (where required) to retrieve information that will be de/serialized when the serializer calls on those properties. It's a bit more coding work, but it does work much better than attempting to force the serializer to just do the right thing.

Just a quick update on this, I have not forgotten! Just doing some more research, looks like I am on to a winner, just need to get the code sorted. So far, I have the following: The XmlSeralizer is basically a class that does some nifty reflection on the classes it is serializing.It determines the properties that are serialized based on the Type.

The reason the problem occurs is because a type mismatch is occurring, it is expecting the BaseType but in fact receives the DerivedType .. While you may think that it would treat it polymorphically, it doesn't since it would involve a whole extra load of reflection and type-checking, which it is not designed to do. This behaviour appears to be able to be overridden (code pending) by creating a proxy class to act as the go-between for the serializer. This will basically determine the type of the derived class and then serialize that as normal.

This proxy class then will feed that XML back up the line to the main serializer.. Watch this space!

It's certainly a solution to your problem, but there is another problem, which somewhat undermines your intention to use "portable" XML format. Bad thing happens when you decide to change classes in the next version of your program and you need to support both formats of serialization -- the new one and the old one (because your clients still use thier old files/databases, or they connect to your server using old version of your product). But you can't use this serializator anymore, because you used type.

AssemblyQualifiedName which looks like TopNamespace.SubNameSpace. ContainingClass+NestedClass, MyAssembly, Version=1.3.0.0, Culture=neutral, PublicKeyToken=b17a5c561934e089 that is contains your assembly attributes and version... Now if you try to change your assembly version, or you decide to sign it, this deserialization is not going to work...

PS: just add this attribute to ctor you do not want be visible and usable: System.ComponentModel. EditorBrowsable(System.ComponentModel. EditorBrowsableState.

Never) public AbstractXmlSerializer() { }.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.