Open GoogleCodeExporter opened 9 years ago
Sure thing: Serializer.NonGeneric.*
Also, in v2, *all* the methods on TypeModel are non-generic (in v2, the
non-generic API is the primary API, with the generic methods simply being
proxies to the non-generic API)
Original comment by marc.gravell
on 15 Aug 2011 at 5:55
This use would be ideal :
object person = new Person();
byte[] buffer = Serializer.Serialize(person);
// Socket Communication Here
object personB = Serializer.Deserialize(buffer);
// MvvMLight Messenger
Messenger.Send(personB);
Original comment by Torak...@gmail.com
on 15 Aug 2011 at 5:57
That is pretty much all there, via NonGeneric. Re deserialize - by itself,
protobuf-net *also* doesn't know the object type unless you tell it. No type
information is embedded by default. My preferred way to handle that scenario is
with the TypeResolver parameter to the WithLengthPrefix methods, where-by you
can associate an integer key with types (in your code - external to
protobuf-net) and do the resolution as part of reading the stream.
Original comment by marc.gravell
on 15 Aug 2011 at 6:38
I experienced hard to find NonGeneric. I feel that by .NET standards it is hard
to discover. From APIs I met, no generic methods good to go with generics. Of
course there some drawbacks because unexpereinced devs will ask why there such
non generics methods, but change will keep Protobuf more on .NET side.
Original comment by asd.and....@gmail.com
on 20 Feb 2013 at 8:29
Perhaps the real thing to do here is to advertise more that the *primary* API
in v2 is actually `TypeModel` (not `Serializer`); the `TypeModel` is
*primarily* non-generic. Indeed, the entire core is non-generic (generics were
causing a few problems)
Original comment by marc.gravell
on 20 Feb 2013 at 2:37
Cool, TypeModel feels better for me, but in namespace I will never look:)
Original comment by asd.and....@gmail.com
on 22 Feb 2013 at 12:00
Original issue reported on code.google.com by
Torak...@gmail.com
on 15 Aug 2011 at 5:18