Question

As it was mentioned in previous posts, when a List of objects (member of a bigger object) is marked with the AsReference attribute, its elements are indeed serialized/deserialized as reference. However
the list itself isn’t serialized as reference. This behavior breaks the integrity of the object graph. In particular, it is different from what the MS BinaryFormatter does. I wonder where does this limitation come from and what would it take to have it as an optional feature?

I evaluate migrating a huge ASP.NET app with an SQL state session from the BinaryFormatter to ProtoBuf-net serialization in order to improve performance. The application has a fairly
complicated data model all saved in the Session, so the above seems to be a potential for bugs. By the way, can you recall other significant differences in behavior between the BinaryFormmater and ProtoBuf.net?

Answer 1

The “what would it take” is simply me getting a few minutes to design, implement (twice: runtime vs meta-programming), unit-test (twice: runtime vs MP), regression-test (twice…), document, deploy, etc. It isn’t a huge thing

A pragmatic option may be to encapsulate the list, so that you don’t directly need to reference the list – i.e. instead of:

objA                 objB
> theList            > theList

you might have

objA                 objB               listWrapper
> listWrapper        > listWrapper      > theList

that is obvious not vastly convenient, but it would work today. Support for this scenario is on my road-map, though.

Re other significant differences… it depends entirely on what your state model is (and in either case I recommend a reasonably simple DTO model here). But things that leap to mind:

• it may be using a different constructor (note: you can disable constructor usage in protobuf-net, as an option)
• depending on how you mark the members, you might be working at property level (BinaryFormatter is field level; protobuf-net can also work at field-level if desired)
• protobuf-net doesn’t have as much support for unexpected types (although DynamicType is an option in some scenarios); generally it prefers to know what the data is going to look like in advance
• protobuf-net doesn’t serialize delegates/events (BinaryFormatter does)
• reference tracking is explicit (opt-in) in protobuf-net, and implicit (automatic) in BinaryFormatter
• and probably a few other things that would occur if I saw the model