Why does protobuf-net append to a byte[] Property/field on deserialize?

[NYCBrit]

I'm using protobuf-net v2 (trunk) to serialize my C# app. I'm confused
by the byte[] serializer (BlobSerializer) which always appends the
deserialized byte[] array to the initialized value, rather than
replacing it. Why does it do this?

Thanks,
Richard

[Marc Gravell]

Hmmm - good question. A bit of an edge case, really, deserializing over the top of an existing byte[], or having duplicated byte[]. But thinking about it, it probably should adhere to the "singular scalar fields" logic and replace rather than accumulate.

I'll log that as a bug. Out of curiosity, is there a specific scenario where this is noticed? (i.e. where it is common)

Marc

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

--
Regards,

Marc

[Richard Geary]

You can repro this with a trivial example with a byte[] as an initialized member field. In my particular case, it was storing some XML describing the layout of the window class (AvalonDock.DockingManager.SaveLayout/RestoreLayout), and the bug was duplicating the XML. This subsequently caused the XmlDocument to throw an exception as there were 2 roots to the xml tree. I fixed it by altering BlobSerializer.RequiresOldValue to return false.

 

Now you mention it, I see why you might want to append to the array, as part of the “append to the existing items”/Merge feature. Might be useful to have an attribute to set this append behaviour per member.

 

Cheers,

Richard

[Marc Gravell]

I'll see if I can add something when I get chance, but note that you could also work around this by using serialization callbacks to detect when deserialization is starting, and wipe the default BLOB. Also, the elusively unreleased "v2"  also optionally supports ctor-skipping (like WCF/DataContractSerializer), so any default field values will not be assigned (the object prior to deserialization is a vanilla all-zero chunk of memory, regardless of any constructor / field-initializer logic).

Marc

On 1 February 2011 00:31, Richard Geary <trist...@googlemail.com> wrote:

You can repro this with a trivial example with a byte[] as an initialized member field. In my particular case, it was storing some XML describing the layout of the window class (AvalonDock.DockingManager.SaveLayout/RestoreLayout), and the bug was duplicating the XML. This subsequently caused the XmlDocument to throw an exception as there were 2 roots to the xml tree. I fixed it by altering BlobSerializer.RequiresOldValue to return false.

 

Now you mention it, I see it’s part of the “append to the list of existing items”/Merge feature. Might be useful to have an attribute to set this append behaviour per field.

 

Cheers,

Richard

 

From: Marc Gravell [mailto:marc.g...@gmail.com]
Sent: 31 January 2011 01:04
To: NYCBrit
Cc: Protocol Buffers
Subject: Re: [protobuf] Why does protobuf-net append to a byte[] Property/field on deserialize?

 

Hmmm - good question. A bit of an edge case, really, deserializing over the top of an existing byte[], or having duplicated byte[]. But thinking about it, it probably should adhere to the "singular scalar fields" logic and replace rather than accumulate.

--
Regards,

Marc