c# - How to choose between protobuf-csharp-port and protobuf-net

Question

I've recently had to look for a C# porting of the Protocol Buffers library originally developped by Google. And guess what, I found two projects owned both by two very well known persons here: protobuf-csharp-port, written by Jon Skeet and protobuf-net, written by Marc Gravell. My question is simple: which one do I have to choose ?

I quite like Marc's solution as it seems to me closer to C# philisophy (for instance, you can just add attributes to the properties of existing class) and it looks like it can support .NET built-in types such as System.Guid.

I am sure both of them are really great projects but what's your oppinion?

Answer 1

I agree with Jon's points; if you are coding over multiple environments, then his version gives you a similar API to the other "core" implementations. protobuf-net is much more similar to how most of the .NET serializers are implemented, so is more familiar (IMO) to .NET devs. And as Jon notes - the raw binary output should be identical so you can re-implement with a different API if you need to later.

Some points re protobuf-net that are specific to this implementation:

• works with existing types (not just generated types from .proto)
• works under things like WCF and memcached
• can be used to implement ISerializable for existing types
• supports inheritance* and serialization callback methods
• supports common patterns such as ShouldSerialize[name]
• works with existing decorated types (XmlType/XmlElement or DataContract/DataMember) - meaning (for example) that LINQ-to-SQL models serialize out-of-the-box (as long as serialization is enabled in the DBML)
• in v2, works for POCO types without any attributes
• in v2, works in .NET 1.1 (not sure this is a huge selling feature) and most other frameworks (including monotouch - yay!)
• possibly (not yet implemented) v2 might support full-graph* serialization (not just tree serialization)

(*=these features use 100% valid protobuf binary, but which might be hard to consume from other languages)