I was working on a large .NET application (.NET 3.5 SP1), and we began to argue about which XML serializer is better for saving application state: user preferences, open windows, queries, and the like. The power of serializers and quality of resulting XML is best investigated on actual samples. I have built a small engine that runs each serializer on a set of samples, captures resulting XML or exception, and saves them in an XML output file. The results of this work are below.
This part contains mostly pure facts and very little analysis. I started to write a long text with insights and recommendations, which grew longer and longer, until I realized I am having a bad case of scope creep. Thus, I decided to apply the agile approach and release the first part without further delay.
XML Serializers Used
Starting with .NET 3.0, there are at least two other serializers available for general use besides
* In .NET 3.5 SP1, Microsoft made a significant change in the behavior of
We were interested primarily in these things:
- Power: What can be serialized and what cannot
- Versioning: How difficult is it to change serialized classes
- Elegancy: How pleasant the resulting XML is to look at (yes, this is subjective)
WCF serializer is run in two modes: the "ref" mode that allows for cycles in the object graph, and the regular mode that does not permit cycles. The following table summarizes the results for .NET 3.5 SP1. This is important because XAML serializer has much better generics support in .NET 4.0.
Brief Analysis of the Serialization Samples
By decorating your classes and properties with custom attributes, you can achieve remarkable control over generated XML.
XmlSerializer is available in all versions of .NET and is familiar to most developers
There is decent versioning support, you can achieve backward compatibility by using old XML attribute names, and when everything else fails, you can do custom serialization with
Null properties are not written to the document by default.
Generic collections are serialized poorly. Sometimes XAML serializer will produce XML it cannot read. Most of this is fixed in .NET 4.0.
Versioning support is poor. When people talk about versioning XAML, they mean writing XAML document in such a way that old readers would understand it. The task of reading a document produced by an old writer is not addressed. If a class does not have a property mentioned in the document, this causes an exception. There is no way to rename the property, or change the manner in which it is (de)serialized. Custom serialization is not supported.
XAML serializer tightly couples XML with exact .NET types. It is impossible to rename a class or put it in a different CLR namespace without breaking backward compatibility.
Null properties are written to the document, unless decorated with
This is the most powerful serializer of all. It can even serialize object graphs with cycles (in "ref" mode).
There is significant control over names of elements and their namespaces, albeit not as strong as with
XmlSerializer, but enough for versioning purposes.
If you implement
IExtensibleDataObject, the deserializer will put all "extra" fields in the catch-all
ExtensionData property. This helps versioning a whole lot.
There are significant differences in behavior depending on the way the type under serialization is decorated. For
[DataContract], only fields and properties marked with
[DataMember] are serialized. For
[Serializable], all fields are serialized by default.
Starting from .NET 3.5 SP1, non-decorated types can be serialized as well, but there is very little control over this serialization. Also, one can neither disable this behavior, nor choose to use older version of the serializer. If your application can run on .NET 3.5 or .NET 3.5 SP1, getting consistent results may be a little difficult.
The XML produced is verbose and sometimes peppered with namespace declarations. Also, the serializer makes elements, not attributes, out of properties.
The serialization engine that produced the above table (with some XSLT) turned to be quite an interesting program. You can download the source here. The application produces a large XML file with sample source and serialization results from all serializers. This file can be then transformed into a table via XSLT.
Based on this brief analysis, I think it is clear that the XAML serializer is not suitable for serializing application state, mostly due to versioning issues and limitations on generics (prior to .NET 4.0).
Whether you use
DataContractSerializer depends on a number of factors and personal preferences. We will look at those in further detail in next parts.
- 30th July, 2010: Initial post