If I have a class defined
[DataContract()]
class MyObject {
[DataMember()]
ImmutableList Strings { get; private set}
}
<
Heh; I can imagine what is happening here... the generated code is probably doing (paraphrasing):
var list = obj.Strings;
while(CanReadNextItem()) {
list.Add(ReadNextItem());
}
The problem is that the BCL immutable API would require you to catch the result each time, i.e.
var list = obj.Strings;
while(CanReadNextItem()) {
list = list.Add(ReadNextItem());
}
obj.Strings = list; // the private set is not a problem for this
Pre-existing list deserialization code doesn't work this way because it has never needed to - and indeed, there are many different implementations of Add, some of which return non-void results which are required to be ignored.
The lack of a non-public constructor may also upset it a bit, but if this was the main problem, I would kinda expect an exception when it tries to create a non-null list.
Of course, in performance terms, the list = list.Add(...) API probably isn't the most appropriate one to use anyway (although it should work).
I blogged on this topic recently (in the context of protobuf-net, which has now been updated to work with these collection types): http://marcgravell.blogspot.co.uk/2013/09/fun-with-immutable-collections.html Hopefully this blog article should explain why the differences mean that it doesn't play nicely with existing serialization techniques, and how serialization libraries might be updated to work with this scenario.
To answer the question directly, I would say the answer is simply: because the required changes to support immutable collections have not yet been made to DataContractSerializer. I have no knowledge of whether there is a plan to address this. But: I happily declare: "works in protobuf-net" ;p