Why is Serializable Attribute required for an object to be serialized

Question

Based on my understanding SerializableAttribute provides no compile time checks, as its all done at runtime, then why is it required for classes to be marked as serializable?

Couldn't sterilizer just try to serialize an object and just fail? isn't it what it does right-now when something is marked, it tries and fails. wouldn't it be better if you had to mark things as unserializable rather than serializable? that way you wouldn't have the problem of libraries not marking things as serializable?

Answer 1

Well that's a good question but then again it is Microsoft so don't ask just conform or move on to something else where your input might be listened to and considered such as an open source platform and language.

Answer 2

As I understand it, the idea behind the SerializableAttribute is to create an opt-in system for binary serialization.

Keep in mind that, unlike XML serialization, which uses public properties, binary serialization grabs all the private fields by default.

Not only this could include operating system structures and private data that is not supposed to be exposed, but deserializing it could result in corrupt state that can crash an application (silly example: a handle for a file open in a different computer).

Answer 3

This is only a requirement for BinaryFormatter (and the SOAP equivalent, but nobody uses that). Diego is right; there are good reasons for this in terms of what it does, but it is far from the only option - indeed, personally I only recommend BinaryFormatter for talking between AppDomains - it is not (IMO) a good way to persist data (to disk, in cache, to a database BLOB, etc).

If this behaviour causes you trouble, consider using any of the alternatives:

• XmlSerializer, which works on public members (not just the fields), but demands a public parameterless constructor and public type
• DataContractSerializer, which can work fully opt-in (using [DataContract]/[DataMember]), but which can also (in 3.5 and above) work against the fields instead

Also - for a 3rd-party option (me being the 3rd party); protobuf-net may have options here; "v2" (not fully released yet, but available as source) allows the model (which members to serialize, etc) to be described independently of the type, so that it can be applied to types that you don't control. And unlike BinaryFormatter the output is version-tolerant, known public format, etc.