My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
Capabilities  
What features does protobuf-net support
Featured
Updated Apr 13, 2012 by marc.gravell

The following is not complete, but is some of the key features available with protobuf-net:

  • fast binary serialization
  • conforms to the "protobuf" specification (with additional features available optionally)
  • highly version tolerant
  • attribute-based configuration, or explicit configuration with parallel and independent models
  • fully thread-safe, so a single model can be used efficiently
  • optimized IL generation with internal caching
  • static serialization dll generation if required
  • serialization callback support
  • automatic string re-use when deserializing
  • optional string re-use when serializing (changes the layout)
  • tree-based serialization with cycle detection (full-graph optional, see later)
  • class, struct, and interface support (note: interfaces cannot be used for the "root" type)
  • fully appendable format (for building long lists of streaming data)
  • streamable deserialization for consuming an endless stream (sockets etc)
  • support for lists and individual items
  • conditional serialization (based on default values or on user-code)
  • support for parameterless constructors, zero-constructors, or user-supplied factory methods for type construction
  • inheritance support, including abstract type support and inheritance of inter-related generic types
  • support for all standard BCL types
  • optional reference-tracking for full-graph support
  • optional support for embedding limited type information, i.e. object
  • direct WCF hooks for "full" .NET to .NET (this does not apply to SL/WP7 etc)
  • can be used to implement ISerializable to streamline remoting
  • optional automatic member selection (contract inference)
  • optional "contract first" schema language (".proto") can be used for type generation, but is not required
  • support for common "proxy" types (EF, NHibernate, etc)

I have certainly missed a great many features here. If there are specific features you are interested in, or want an example for, let me know.

Comment by ray.rizzuto@gmail.com, Apr 23, 2012

The google version of protoc generates a method that "returns a human-readable representation of the message, particularly useful for debugging." for each message defined in the .proto file. The method is DebugString? in C++, str() in python, and toString in Java. I've used the C++ protoc compiler, and the DebugString? really was helpful since it recursively dumps all fields in all messages. Does protobuf-net have some mechanism to do something similar?

Comment by project member marc.gravell, Apr 23, 2012

@ray.rizzuto no; the debug/string API has not been implemented

Comment by a.marre...@gmail.com, Jun 7, 2012

No serializer defined for type: System.Drawing.Color

Comment by project member marc.gravell, Jun 7, 2012

@a.marretta right; and did it claim to serialize System.Drawing.Color ? That isn't quite what I'd call a core BCL type (it is more GDI+ than anything).

Comment by richard...@finpa.com.au, Nov 5, 2012

No serializer defined for type System.DateTimeOffset?. Would it be included soon? V1 did have it, but missed milliseconds part. We have to use 2 fields (DateTime? + TimeSpan?) to support it.

Comment by project member marc.gravell, Nov 5, 2012

There has never been explicit support for DateTimeOffset?; if it worked in v1, then it might work in v2 if you set AllowParseableTypes to true.

Comment by jankor...@gmail.com, Sep 12, 2013

Im making an application that has to support synchronisation of data with different versions of the program. This means that the server has an object Person with name and adres attributes, but the client has an object Person with only a name attribute. Can i still use this type of synchronisation?

Comment by project member marc.gravell, Sep 12, 2013

@jankorf91 yes

If it is acceptable just to ignore the unknown fields, then: do nothing - they will be dropped on the floor and quietly ignored. If you want to retain round-trip support (i.e. the server sends it to the client with an address, and even though the client doesn't know about address, it comes back with an address) - then simply derive the type from Extensible.

Comment by vishn...@gmail.com, Oct 25, 2013

which version of protobuf compiler is protobuf-net r688 complaint with? is it 2.5.0? Also is there a way to get this version information from API?

Thanks for your time.

Comment by project member marc.gravell, Oct 25, 2013

It is compliant with the protobuf specification; since it is a parallel implementation, it is a bit hard to compare to google protobuf version numbers. AFAIK the last change to the actual wire spec was "packed arrays", and it has supported that since about 2 days after "packed arrays" were announced.

Comment by vishn...@gmail.com, Oct 28, 2013

Thanks for the reply. I need to rephrase my question better. Protobuf specification itself should have version which all implementations should be compliant to specific version of specification, isn't it? So that proto spec version is handshaked between two systems to make sure both of them support same set of required features.


Sign in to add a comment
Powered by Google Project Hosting