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

Answer 1

I just switched from protobuf-csharp-port to protobuf-net because:

• protobuf-net is more ".net like", i.e. descriptors to serialise members instead of code generation.
• If you want to compile protobuf-csharp-port .proto files you have to do a 2 step process, i.e. compile with protoc to .protobin and then compile that with protoGen. protobuf-net does this in one step.

Answer 2

Are you using other languages in your project as well? If so, my C# port will let you write similar code on all platforms. If not, Marc's port is probably more idiomatic C# to start with. (I've tried to make my code "feel" like normal C#, but the design is clearly based on the Java code to start with, deliberately so that it's familiar to those using Java as well.)

Of course one of the beauties of this is that you can change your mind later and be confident that all your data will still be valid via the other project - they should be absolutely binary compatible (in terms of serialized data), as far as I'm aware.

Answer 3

According to it's GitHub project site protobuf-csharp-port has now been folded into the main Google Protocol Buffers project, so it will be the official .NET implementation of protobuf 3. protobuf-net however was last updated in 2013, although there have been some commits recently in GitHub.

Answer 4

In my case I want to use protocol buffers to replace an xml based communication model between a .net client and a j2ee backend. Since I'm already using code generation I'll go for Jon's implementation.

For projects not requiring java interop I'd choose Marc's implementation, especially since v2 allows working without annotations.

Answer 5

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)