Question

What are the deficiencies of the built-in BinaryFormatter based .Net serialization? (Performance, flexibility, restrictions)

Please accompany your answer with some code if possible.

Example:

Custom objects being serialized must be decorated with the [Serializable] attribute or implement the ISerializable interface.

Less obvious example:

Anonymous types can not be serialized.

Answer 1

If you mean BinaryFormatter:

• being based on fields, is very version intolerant; change private implementation details and it breaks (even just changing it to an automatically implemented property)
• isn't cross-compatible with other platforms
• isn't very friendly towards new fields
• is assembly specific (metadata is burnt in)
• is MS/.NET specific (and possibly .NET version specific)
• isn't obfuscation-safe
• isn't especially fast, or small output
• doesn't work on light frameworks (CF?/Silverlight)
• has a depressing habit of pulling in things you didn't expect (usually via events)

I've spent lots of time in this area, including writing a (free) implementation of Google's "protocol buffers" serialization API for .NET; protobuf-net

This is:

• smaller output and faster
• cross-compatible with other implementations
• extensible
• contract-based
• obfuscation safe
• assembly independent
• is an open documented standard
• works on all versions of .NET (caveat: not tested on Micro Framework)
• has hooks to plug into ISerializable (for remoting etc) and WCF