Note that there are some explanatory texts on larger screens.

plurals
  1. POIs it possible to (de)serialize a private property using protobuf-net in Silverlight?
    primarykey
    data
    text
    <p>As we know Silverlight does not allow private reflection. Still, I have a public property with a private setter, which I need to be able to serialize (no problem here) and deserialize (bummer).</p> <p>I know that nothing in the world would make protobuf-net write to this property in Silverlight, this must be done from within the client type (or assembly, if the property is made internal).</p> <p>Is there a scheme in place in protobuf-net for Silverlight, which makes it possible? I could make the type implement some specialized protobuf-net interface (like IProtoSerializable, for instance).</p> <p>Thanks.</p> <p><strong>EDIT</strong></p> <p>I can propose a scheme like that:</p> <pre><code>[ProtoMember(N, SetterMethod = "DeserializePropValue")] public string property Prop { get { return m_prop; } private set { m_prop = value; } } public void DeserializePropValue(ProtoValue&lt;string&gt; value) { m_prop = value.Value; } </code></pre> <p>Where the type ProtoValue is public, but its constructors are internal, so that only protobuf-net assembly can create instances of that type. And of course, protobuf-net will not expose any public API to create ProtoValue objects.</p> <p>This scheme can be supported for Silverlight platform only, other platforms will just invoke the private setter.</p> <p>What do you think?</p> <p><strong>EDIT2</strong></p> <p>I wish to note that surely one can still obtain a reference to an arbitrary PropValue&lt;T&gt; instance, but this will not be accidentally and these are the accidental overwrites of the property, that I wish to eliminate. Plus, I want to keep the setter non public, so that it does not surface in various reflection based binding mechanisms used in UI.</p> <p><strong>EDIT3</strong></p> <p>The PropValue&lt;T&gt; instances can be made unsuitable for storage, meaning after the method DeserializePropValue returns, the respective PropValue instance is invalidated. This leaves only one way to abuse it, like so:</p> <pre><code>[ProtoContract] public class Abusee { [ProtoMember(1, SetterMethod = "DeserializePropValue")] public string property Prop { get; private set; } public void DeserializePropValue(ProtoValue&lt;string&gt; value) { m_prop = value.Value; } } [ProtoContract] public class Abuser { private Abusee m_abusee; public Abuser(Abusee abusee, string newPropValue) { m_abusee = abusee; Dummy = newPropValue; Serializer.DeepClone(this); } [ProtoMember(1, SetterMethod = "DeserializeDummyValue")] public string property Dummy { get; private set; } public void DeserializeDummyValue(ProtoValue&lt;string&gt; value) { m_abusee.DeserializePropValue(value); } } </code></pre> <p>Quite a lot of effort to happen by accident. As to intentional abuse - there is no regression here. One can always serialize an object, manipulate the binary serialization data and then deserialize it back. The regression is only in the ease of abuse. However, my goal is to:</p> <ul> <li>Prevent mistakes by accident</li> <li>Keep the setter non public</li> <li>Avoid the maintenance nightmare associated with surrogates.</li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload