Serializable Classes

As the examples demonstrated, simple serialization required no custom code to write or read the XML. We wrote the state of an object to an XML document on disk, read the document back in and turned it into an object entirely by leveraging services provided by the .NET Framework. We did not write any code to generate XML elements or attributes; all this was done behind the scenes. “Where’s the catch?” you may ask. Well, there are quite a few requirements for classes the

XmlSerializer can process. The design goal for the XmlSerializer to run in applications with limited permissions is responsible for a number of restrictions on the classes that can be serialized:

• The serialized class must be public, because you cannot analyze internal and private types through without granting certain permissions to the executing application. Yet the XmlSerializer is designed to operate without any special security settings.
• The serialized class must have a default (parameter-less) constructor, because the
• Deserialize() method needs to be able to instantiate an object in unsafe environments before it can set all the fields. Instantiating an object without calling the constructor would require certain permissions.
• No code executing inside a property accessor may require any security privileges, because the
• XmlSerializer ensures that it can deserialize the types it processes in unsafe environments.
• Properties must be read/write. Read-only properties will be ignored because they cannot be set without special permissions when an object is deserialized.
• All these restrictions ensure that the XmlSerializer is fully functional even in applications running from the network or even the internet, because their permission sets are very limited.

Unfortunately there are more restrictions on the types the XmlSerializer can process. Some of them are restrictions of the current implementation of the XmlSerializer. Make sure you know about the restrictions below when you develop classes you intend to process with the XmlSerializer:

• Properties and fields may not return interfaces. Abstract base classes are OK.
• Multi-dimensional arrays can not be mapped to XML, You have to use nested arrays instead.
• Object identity is not preserved when an object is serialized with the

XmlSerializer. When you serialize an object graph in which an object is referenced from multiple other objects the referenced object is serialized each time it is referenced.

• Type safety is not guaranteed when deserializing an object. You can map serialize and deserialize XML documents with different .NET classes as long as they map to the same XML layout. This is an important feature, since different applications can exchange data without requiring the same classes.
• Object graphs cannot contain circular references, i.e. you cannot serialize constructs like doubly linked lists.
• Collections must not implement IDictionary, like the Hashtable for example

These limitations pose no major difficulties in data-driven applications where the data layout   is the primary focus, not object type and identity. Yet they make it very hard to serialize anything else but classes specifically designed for XML data binding scenarios.

There are some classes throughout the .NET framework designed with these requirements in mind. In fact, in some case it is the other way around. The XmlSerializer has built-in support to enable XML data binding for certain types and classes, such as:

• Array types
• Collections, implementing ICollection or IEnumerable, but not IDictionary, for example the ArrayList
• Objects of types derived from XmlNode
• DateTime and TimeSpan objects.

DataSet objects (weak and strongly-typed). DataSets are objects to access data stored in a database.

The .NET Framework offers alternatives to serialize objects if the restrictions do not work in your scenario: The SoapFormatter does not impose some of these limitations and serializes objects into an XML-based format also. It is intended when you use XML and the SOAP protocol to execute code on other servers. The BinaryFormatter also serializes the complete object state, ensures type-safety, but uses a binary format to store the information. Both classes are located in the System.Runtime.Serialization namespace