Question

What’s wrong with the following code?

MyList l = Serializer.DeepClone(new MyList { "abc" });
Console.WriteLine(l.Count == 1);

Where:

[ProtoContract]
public class MyList : List<String>
{
}

Expected: true, actual: false.

Answer 1

If you want an immediate fix, just take away the [ProtoContract]; lists have inbuilt behaviour, and don’t need to be marked as contracts.

It looks like in this case the contract definition is taking precedence over the fact that it is a list; I will need to look carefully to see if changing this causes any unwanted side-effects.

Working example:

public class MyList : List<string>{}

[Test]        
public void ListSubclassShouldRoundTrip()
{
    var list = new MyList { "abc" };
    var clone = Serializer.DeepClone(list);
    Assert.AreEqual(1, clone.Count);
    Assert.AreEqual("abc", clone[0]);
}

currently broken example:

[ProtoContract]
public class MyContractList : List<string> { }

[Test]
public void ContractListSubclassShouldRoundTrip()
{
    var list = new MyContractList { "abc" };
    var clone = Serializer.DeepClone(list);
    Assert.AreEqual(1, clone.Count);
    Assert.AreEqual("abc", clone[0]);
}

---

Update; however, it looks like this should work, since it works fine when the list is a member of a type; the problem only occurs when the list is the outermost type in a graph. Example (all tests pass):

[ProtoContract]
public class ListWrapper
{
    [ProtoMember(1)]
    public List<string> BasicList { get; set; }
    [ProtoMember(2)]
    public MyList MyList { get; set; }
    [ProtoMember(3)]
    public MyContractList MyContractList { get; set; }
}

[Test]
public void TestBasicListAsMember()
{
    var obj = new ListWrapper { BasicList = new List<string> { "abc" } };
    var clone = Serializer.DeepClone(obj);
    Assert.IsNull(clone.MyList);
    Assert.IsNull(clone.MyContractList);
    Assert.AreEqual(1, clone.BasicList.Count);
    Assert.AreEqual("abc", clone.BasicList[0]);
}

[Test]
public void TestMyListAsMember()
{
    var obj = new ListWrapper { MyList = new MyList { "abc" } };
    var clone = Serializer.DeepClone(obj);
    Assert.IsNull(clone.BasicList);
    Assert.IsNull(clone.MyContractList);
    Assert.AreEqual(1, clone.MyList.Count);
    Assert.AreEqual("abc", clone.MyList[0]);
}

[Test]
public void TestMyContractListAsMember()
{
    var obj = new ListWrapper { MyContractList = new MyContractList { "abc" } };
    var clone = Serializer.DeepClone(obj);
    Assert.IsNull(clone.BasicList);
    Assert.IsNull(clone.MyList);
    Assert.AreEqual(1, clone.MyContractList.Count);
    Assert.AreEqual("abc", clone.MyContractList[0]);
}

---

Update update: this was a subtle bug, caused by the many different ways that lists can behave; in the case of lists as members that have getters and setters, it has some logic that says “if we get the list, and it wasn’t null, don’t call the setter – just add”. However, the code that handles types-that-are-lists was accidentally enabling that mode. So what was happening was: it would deserialize the data, then proclaim “you can discard this value” – which it dutifully did. Then the “never return null” code would just create a new list, and return that instead. Annoyingly, just a one-liner to fix, and no side-effects; fixed in r555.

Whenever someone gets stuck, I add an integration test; so this shouldn’t happen again