2. 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

3. 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 the
reverse 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 line
through 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:

4. 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.

5. 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 the
particular 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.

6. 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.

7. 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? This
might 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.

9. 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 serializer
needs 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.