Question

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).

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).

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).

Thanks.

EDIT

I can propose a scheme like that:

[ProtoMember(N, SetterMethod = "DeserializePropValue")]
public string property Prop
{
  get { return m_prop; }
  private set { m_prop = value; }
}

public void DeserializePropValue(ProtoValue<string> value)
{
  m_prop = value.Value;
}

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.

This scheme can be supported for Silverlight platform only, other platforms will just invoke the private setter.

What do you think?

EDIT2

I wish to note that surely one can still obtain a reference to an arbitrary PropValue<T> 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.

EDIT3

The PropValue<T> 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:

[ProtoContract]
public class Abusee
{
    [ProtoMember(1, SetterMethod = "DeserializePropValue")]
    public string property Prop { get; private set; }

    public void DeserializePropValue(ProtoValue<string> 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<string> value)
  {
    m_abusee.DeserializePropValue(value);
  }
}

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:

• Prevent mistakes by accident
• Keep the setter non public
• Avoid the maintenance nightmare associated with surrogates.

Answer 1

Interesting question. There is a concept of “surrogates” in v2, which was designed for immutable objects (and structs), which might be of use – it depends how complex the object is as to how attractive an option that is. A second option might be to make the property exhibit popsicle immutability. I will illustrate both, but:

• popsicle immutability in this case is only semi-popsicle, and could easily be side-stepped; this option is convenient, and may be useful if you just want to prevent accidental damage
• true immutability gives you stronger protection; essentially the surrogate acts as a “builder”, but that never allows you to mutate an existing instance

Note that surrogates can’t be specified on an attribute at the moment (I might add that later ;p) – so I’ve used the runtime model to demonstrate this:

class Program
{
    static void Main()
    {
        var obj = new Popsicle(3, 4);
        var clone = Serializer.DeepClone(obj);
        Debug.Assert(clone.Foo == obj.Foo);
        Debug.Assert(clone.Bar == obj.Bar);

        var model = TypeModel.Create();
        model.Add(typeof(MutableSurrogate), false).Add("Foo", "Bar");
        model.Add(typeof(ImmutableType), false).SetSurrogate(typeof(MutableSurrogate));
        // note you should re-use models (cache them) - or better: pre-generate a serializer dll
        var obj2 = new ImmutableType(5, 6);
        var clone2 = (ImmutableType)model.DeepClone(obj2);
        Debug.Assert(clone2.Foo == obj2.Foo);
        Debug.Assert(clone2.Bar == obj2.Bar);
    }
}

[ProtoContract] // should also work with DataContract etc
public class Popsicle
{
    public Popsicle() { }
    public Popsicle(int foo, int bar)
    {
        Foo = foo;
        this.bar = bar;
    }
    private int isBeingDeserialized;

    [ProtoBeforeDeserialization]
    public void BeforeDeserialization()
    {
        isBeingDeserialized++;
    }
    [ProtoAfterDeserialization]
    public void AfterDeserialization()
    {
        isBeingDeserialized--;
    }
    [ProtoMember(1)]
    public int Foo { get; set; } //  fully mutable

    private int bar;
    [ProtoMember(2)]
    public int Bar
    {
        get { return bar; }
        set
        {
            if (bar == value) return;
            if (isBeingDeserialized <= 0) throw new InvalidOperationException();
            bar = value;
        }
    }
}

public class ImmutableType
{
    private readonly int foo, bar;
    public ImmutableType(int foo, int bar)
    {
        this.foo = foo;
        this.bar = bar;
    }
    public int Foo { get { return foo; } }
    public int Bar { get { return bar; } }
}
public class MutableSurrogate
{
    public static implicit operator ImmutableType(MutableSurrogate surrogate)
    {            
        return surrogate == null ? null
            : new ImmutableType(surrogate.Foo, surrogate.Bar);
    }
    public static implicit operator MutableSurrogate(ImmutableType surrogate)
    {
        return surrogate == null ? null
            : new MutableSurrogate { Foo = surrogate.Foo, Bar = surrogate.Bar };
    }
    public int Foo { get; set; }
    public int Bar { get; set; }
}

I don’t currently have anything like an IProtoSerializable. I’m still waiting to find that one thing that truly needs it… I’m not sure this is it.