(Hmmm, today I can't see the [protobuf-net] that I added to the

I knew about that option, actually, my app is using that approach. I'm
using protobuf-net with WCF, keeping existent [DataContract]/
[DataMember] attributes, and have a base class AbstractMessage with
some common information.

I have some CRUD operations that are common to a lot of entities in my
app, so I ended up creating some generic messages GetAll<T>, Edit<T>,
Save<T>, Validate<T>, etc... That's the use case I have, but I don't
know if its general enough to be added to protobuf-net.

By the way, I've made some changes to source code (from rev 250). If
you like a patch to review it or more information, pls let me know
(maybe some change is useful for someone else).

Thanks for the excellent job you are doing with this library, Mark.

On 12 mayo, 22:38, Marc Gravell <marc.grav...@gmail.com> wrote:
> > Note the subject line -- it's protobuf-net.  :)
> I see "Class hierarchy serialization" using google-groups.
> (ahhh - if you expand "More options" you see the full "[protobuf-net]
> Class hierarchy serialization" - interesting!)
> OK - to expand:
> protobuf-net supports class hierarchies, which is does by representing
> subtypes as nested messages (to make it wire compatible), with a bit
> of magic thrown in. What it *doesn't* currently support is the open
> generic type (GetAll<T>) in the middle of the stack. This is in part
> because you need to declare the metadata that it uses to identify
> subtypes in the type defintion.
> Without the open type, then yes - it is fine:
>     [ProtoContract, ProtoInclude(1, typeof(CarMessage))]
>     class AbstractMessage {...}
>     [ProtoContract]
>     class CarMessage : AbstractMessage {...}
> Now, regardless of whether you use CarMessage or AbstractMessage when
> using Serializer, it will identify the correct type. So if you
> serialize an AbstractMessage you will get back an AbstractMessage; if
> you serialize CarMessage (as either an AbstractMessage or a
> CarMessage) you will always get back a CarMessage (regardless of
> whether you ask for an AbstractMessage or a CarMessage).
> If there is a good use-case for supporting open generic types, then
> that approach *might* fit into the work I'm currently doing that lets
> you specify the model separately to the main class definitions. It
> wasn't on my plan (and it would have to wait a little bit until I've
> completed the current refactor), but it could *potentially* work -
> *if* there is a good scenario for it...
> Marc Gravell
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to