Serialization is the run-time process that converts an object, or a graph of objects, to a linear sequence of bytes.

You can then use the resultant block of memory either for storage or for transmission over the network on top of a

particular protocol. In the Microsoft .NET Framework, object serialization can have three different output forms:

binary, Simple Object Access Protocol (SOAP), and XML.

Run-time object serialization (for example, binary and SOAP) and XML serialization are significantly different

technologies with different implementations and, more important, different goals. Nevertheless, both forms of

serialization do just one key thing: they save the contents and the state of living objects out to memory, and from

there to any other storage media. Run-time serialization is governed by .NET Framework formatter

objects. XML serialization takes place under the aegis of the XmlSerializer class

The XML serialization process converts the public interface of an object to a particular XML schema. Such a mechanism is widely used throughout the .NET Framework as a way to save the state of an object into a stream or a memory buffer.

The Object Serialization Process

In the .NET Framework, object serialization is offered through the classes in the System.Runtime.Serialization namespace. These classes provide type fidelity and support deserialization. As you probably know, the deserialization process is thereverse of serialization. Deserialization takes in stored information and recreates objects from that information.

The SOAP Formatter

To use the SOAP formatter, you must reference a distinct assembly— System.Runtime.Serialization.Formatters.Soap. You add this separate assembly through the Add Reference dialog box or manually on the compiler's command linethrough the /reference switch. In addition to linking the assembly to the project, you still have to import the namespace with the same name as the assembly, as shown here:

From SOAP to XML Serialization

A second, very special type of .NET Framework serialization is XML serialization. Compared to ordinary .NET Framework object serialization, XML serialization is so different that it shouldn't even be considered another type of formatter. It is similar to SOAP and binary formatters because it also persists and restores the object's state, but when you examine the way each serializer works, you see many significant differences.

XML serialization is handled by using the XmlSerializer class, which also enables you to control how objects are encoded into elements of an XML schema. In addition to differences in goals and implementation details, the strongest difference between runtime and XML serialization is in the level of type fidelity they provide.

The primary goal of XML serialization is making another application, possibly an application running on a different platform, effectively able to consume any stored data. Let's recap the key differences between run-time and XML serialization:

Persisted properties Run-time serialization takes into account any properties, regardless of the scope a property has in the context of the class. XML serialization, on the other hand, avoids private, protected, and read-only properties; does not handle circular references; and works only with public classes. In addition, if one property is set to null in theparticular instance being serialized, the XML serializer just ignores the property. The XML serializer never includes type information. .. Object identity Run-time serialization maintains information about the original class name, namespace, and assembly. All this information—the object's identity—is irreversibly lost with XML serialization. .. Control of the output Run-time serialization lets you indicate the data to serialize by adding values to a cargo collection. You can't control how these values are actually written, however. The schema of the persisted data is fixed and hard-coded in the formatter. In this respect, the XML serializer is much more flexible. The XML serializer lets you specify namespaces, the name of the XML element that will contain a particular property, and even whether a given property should be rendered as an attribute, text, or an element.

The XML Serializer

The central element in the XML serialization architecture is the XmlSerializer class,which belongs to the System.Xml.Serialization namespace. The XML serialization process is articulated in the following steps:1. The serializer generates an XSD schema for the target class that includes all the public properties and fields.2. Using this XSD schema, the serializer generates a C# source file with a made-to-measure reader and writer class. The source file is compiled into a temporary assembly.The Serialize and Deserialize methods are simply higher level interfaces for those writer and reader classes. This list does not cover all the features of XML serialization, but it certainly focuses on the key aspects. Let's look more closely at these key aspects before we move on to more advanced issues such as customizing the XSD schema being generated and hooking up the deserialization process.

The XML serializer works on top of a particular type—the target class. While deserializing, the deserializer engine attempts to fit incoming data into the properties of the target class, taking into careful account any attributes set for the various properties. What happens if the source and the destination follow incompatible schemas? Thismight seem a rather odd situation—how could you deserialize data that you haven't previously serialized?—but in practice it exemplifies the real goal of XML serialization. Beyond any technological and implementation details, XML serialization is simply a way to automatically instantiate classes from XML data.

The XML serializer is a double-edged sword. On one hand, it lets you serialize and deserialize even complex .NET Framework classes to and from XML with very few lines of code. To accomplish this, the serializerneeds to create an assembly on the fly. If you don't use a global instance of the serializer for each type, you can easily add hundreds of milliseconds of overhead to each call—definitely not a pleasant prospect

On the other hand, appropriately used, XML serialization produces more compact code than run-time SOAP serialization. If you add type information, and SOAP type information in particular, the ratio changes, however. The moral of this story is don't ever mix XML and SOAP—use only the process you need.Serialization is one of the new frontiers of XML. It is not clear yet whether today's SOAP, extensions to SOAP, or a brand-new dialect will become the universal platform for describing objects. Currently, XML serialization is a hybrid, incomplete, technology. Originally designed as a tool running underneath the .NET Framework implementation of Web services, XML serialization entered prime time a bit too early, or if not too early, certainly not optimized.