.NET Reference Guide

Serialization

Last updated Jan 1, 2004.

In the "Serializing Objects" topic of the .NET Framework SDK, serialization is defined as "the process of converting the state of an object into a form that can be persisted or transported." Simple, right? The process of re-constituting an object from the serialized data is called "deserialization." The serialization mechanisms in the .NET Framework allow you to save the state of your object and then re-constitute the object at a later time from the saved data. That's the simple description. But it gets complicated in a hurry.

The .NET Framework supports two types of serialization, what it calls Binary Serialization and XML Serialization. The official documentation has this to say about the two types of serialization:

• Binary serialization preserves type fidelity, which is useful for preserving the state of an object between different invocations of an application. For example, you can share an object between different applications by serializing it to the Clipboard. You can serialize an object to a stream, to a disk, to memory, over the network, and so forth. Remoting uses serialization to pass objects "by value" from one computer or application domain to another.

• XML serialization serializes only public properties and fields and does not preserve type fidelity. This is useful when you want to provide or consume data without restricting the application that uses the data. Because XML is an open standard, it is an attractive choice for sharing data across the Web. SOAP is likewise an open standard, which makes it an attractive choice.

So binary serialization will save the entire object state, and XML serialization will only save some of the object's data. To further muddy the waters, binary serialization does not necessarily imply that the object's state will be stored in binary format. You can store it in a binary form, but you can also specify that the object's state be represented in SOAP format. That's right: SOAP format (that is, XML), binary serialization. The "binary" in "binary serialization" means that the information required to create an exact binary copy of the object is saved. Does your head hurt yet? Let's add another wrinkle: you can also use XML serialization to create SOAP messages.

The most important thing to realize about the two serialization types is that they're completely different from each other. Binary serialization creates a complete representation of an object's state. If you use binary serialization to persist an object, deserializing it will give you an exact copy. XML serialization, on the other hand, will only persist public properties.

When you decide that you need to serialize an object, you need to decide which type of serialization is right for you. Binary serialization is attractive because it can be used to share objects among applications. In addition, binary serialization allows you to store the data in binary form, saving disk space. The disadvantage is that only .NET programs that have definitions of the object types can make sense of the persisted object. XML serialization has the benefit of being human-readable, and accessible by most modern programming languages and systems. It is an ideal choice for sharing information between applications that don't understand the .NET type system or the particular types that you use in your program. However, being a purely text format, the XML representation of an object will almost always be much larger than the equivalent binary representation.