Being a developer that takes a lot from the internet, I decided to contribute some of my own. I always had some vague concepts regarding .NET serialization, and yesterday, I got it all clarified. Internet could be a great resource, but it can also be greatly misleading. This article tries to clarify the concepts of .NET Serialization and XML Serialization.
When I first looked up the term serialization, basically, I got redirected to sites that explained how to turn an object to an XML representation. Let's call that XML serialization, a term that I do not actually like. But .NET serialization is not that. It is the mechanism to transport data through Remoting.
The majority of articles on the internet have it wrong. There is no need for the class to be marked as
[Serializable] or implement
ISerializable. XML serialization actually uses Reflection to find any public properties or fields, and then creates the corresponding XML node. Deserialization also works that way.
This is a sample general class for producing an XML string from an object, and its reverse procedure:
public class Serializer
public static string ObjectToString(object obj)
XmlSerializer serializer =
new XmlSerializer(obj.GetType(), "");
StringWriter writer = new StringWriter();
serializer.Serialize(writer, obj, null);
public static bool StringToObject(string data,out object obj)
obj = null;
XmlSerializer serializer =
StringReader reader = new StringReader(data);
One of the most noted features of .NET is serialization. The feature is used to transport data between Remoting calls. Behind the scenes, something like this happens for the binary transport protocol:
MemoryStream ms = new MemoryStream();
BinaryFormatter bFormatter = new BinaryFormatter();
Object_Type obj = (Object_Type)bformatter.Deserialize(ms);
The class to be serialized must be marked with the
[Serializable] attribute, and optionally must implement the
ISerializable interface. The .NET automated mechanism uses Reflection to find what needs to be serialized. Because this is not XML serialization, classes that implement
IDictionary and other interfaces cannot be serialized.
In order for deserialization to work, extra info is wrapped with the actual binary data that describes what data is for what in a matter of way. This makes the data produced larger, but keeps the job done for every valid serializable class.
If we want to override this mechanism, the class must implement
void ISerializeble.GetObjectData (SerializationInfo info, StreamingContext ctxt) is called by the CLR to acquire the serialized data, and
public MyObject(SerializationInfo info, StreamingContext ctxt) is used to populate the objects data according to serialization data, usually received through a Remoting call.
In the above methods, because we know exactly what we are going to add to the serialization stream, we gain speed because Reflection is not used. And if our data coding is clever enough, we gain from the smaller size of data that needs to be transferred.
Points of Interest
As you can see, .NET serialization is an entirely different concept from XML serialization. In my opinion, XML serialization should only be used to store configuration files and option classes in a Registry key.
For more info about how to implement custom serialization and get performance gain, look at Tim Haynes Fast Serialization article, based on which I finally clarified things in my mind.
Any terminology I have used, like .NET serialization and XML serialization, might be incorrect.