For which scenarios is protobuf-net not appropriate?

Question

We have been using BinarySerialization with our C# app, but the size and complexity of the classes which need to be serialized results in sloooooow (de)serialization, and large files.

We suspect that we should just write our own custom serializers; but protobuf-net claims significant speed and size advantages over standard .Net binary serialization, and may be easier to add to our app than a large number of bespoke serializers.

Before spending significant time and effort trying to get it to work for us, I would love to know whether there are any deal-breakers. We are using properties defined with interfaces, generic lists of abstract sub-classes, custom bit flag enums, etc etc etc. What would stop protobuf-net working for us?

Answer 1

It's not appropriate when you have to interact with existing software / an existing standard. For example, you can't use it to communicate with an SMTP server.

Answer 2

protobuf-net does what it can to adhere to the core protobuf spec, and then some (for example, it includes inheritance), however:

• v1 is not very good at interface-based properties (i.e. ICustomer etc); I'm working on getting this improved in v2
• v1 likes there to be a parameterless constructor (this requirement is lifted in v2)
• you need to tell it how to map the model to fields; in v1 this needs to be decorated on the type (or there is an option to infer some things from the names etc); in v2 this can be done externally
• in v1, flags enums are a pain; in v2 there is an option to pass-thru enums as raw integers, making it much more suitable for falgs
• abstracts and inheritance are fine, but you must be able to determine all the concrete types ahead of time (to map them to integer keys)
• generics should be fine
• jagged arrays / nested lists without intermediate types aren't OK - you can shim this by introducing an intermediate type in the middle
• not all core types have inbuilt support (the new date/time offset types, for example); in "v2" you can introduce your own shims for this if necessary
• it is a tree serializer, not a graph serializer; I have some thoughts there, but nothing implemented yet

If there is some limited example of what you want to serialize, I'll happily take a look to see if it is likely to work (I'm the author).

Answer 3

Please read this here on a blog about protobuf-net, to quote

What’s the catch?

In the most part, that’s it. WCF will use protobuf-net for any suitable 
objects (data-contracts etc). Note that this is a coarser brush than the 
per-operation control, though (you could always split the interface into 
different endpoints, of course).

Also, protobuf-net does have some subtle differences (especially regarding empty 
objects), so run your unit tests etc.

Note that it only works on the full-fat WCF; it won’t help Silverlight etc, since 
it lacks the extension features – but that isn’t new here.

Finally, the resolver in WCF is a pain, and AFAIK wants the full assembly details 
including version number; so one more thing to maintain when you get new versions. 
If anyone knows how to get around this?