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

Question

I recently had to look for a port to the C # protocol buffer library originally developed by Google. And guess what, I found two projects that are owned as two very famous people: protobuf-csharp-port , written by Jon Skeet and protobuf-net , written by Mark Gravell . My question is simple: which one do I need to choose?

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

I am sure that both of them are really great projects, but what is your opponent?

Answer 1

I agree with John's points; if you code several environments, then its version gives you a similar API for other "core" implementations. protobuf-net is much more similar to how most of the .NET serializers are implemented, so it’s more familiar (IMO) for .NET developers. And, as John notes, the raw binary output must be identical so that you can re-implement with another API if you need to later.

Some re protobuf-net points that relate 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 methods * and serialization processing methods
• supports common patterns such as ShouldSerialize[name]
• works with existing decorated types ( XmlType / XmlElement or DataContract / DataMember ) - which means (for example) that LINQ-to-SQL models serialize ready-made ones (as long as serialization is included in DBML)
• in v2, works for POCO types without any attributes
• in v2 works in .NET 1.1 (not sure if this is a huge selling function) and most other frameworks (including monotouch - yay!)
• perhaps (not yet implemented) v2 can support full-graph serialization (and not just tree serialization)

(* = these functions use a 100% valid protobuff binary, but which can be difficult to consume from other languages)

Answer 2

Do you use other languages ​​in your project? If so, my C # port will allow you to write similar code on all platforms. If not, the Marc port is probably more idiomatic C # for starters. (I tried to make my code “feel” like regular C #, but the design is clearly based on Java code to begin with, deliberately to be familiar with those who use Java.)

Of course, one of the beauties of this is that you can change your mind later and be sure that all your data will still be valid through another project - they must be absolutely binary (in terms of serialized data), since I know.

Answer 3

According to it , the GitHub project site protobuf-csharp-port is now folded into the main Google Buffer Buffers project, so this will be the official implementation of .NET protobuf 3. protobuf-net, however, it was last updated in 2013 , although there were some commits recently appeared on github .

Answer 4

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

• protobuf-net is more than ".net like", that is, descriptors for serializing elements instead of generating code.
• If you want to compile the protobuf-csharp-port.proto files, you need to perform a two-step process, that is, compile with protoc in .protobin and then compile it with protoGen. protobuf-net does this in one step.

Answer 5

In my case, I want to use protocol buffers to replace the xml-based communication model between the .net client and the j2ee file. Since I already use code generation, I will go to the Jon implementation.

For projects that do not require java interop, I would choose the Marc implementation, especially since v2 allows you to work without annotations.