IList<T> serialization

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Type t=typeof(IList<ModelType>)
2. int key = RuntimeTypeModel.Default.GetKey(t)
3.

What is the expected output? What do you see instead?
key >= 0

What version of the product are you using? On what operating system?
v2.431

Please provide any additional information below.

This code is used in your ProtoOperationBehavior.CreateSerializer() (for WCF) 
and this method returns DataContractSerializer instead of XmlProtoSerializer 
for IList<ModelType> or any IList<>/ObservableCollection<T> types. 
As I see, RuntimeTypeModel.RecogniseCommonTypes(), that`s called when type 
isn`t recognized support only KeyValuePair<,> but no other.
I did something wrong or PTB doesn`t support serialization of objects 
list/collection?

Original issue reported on code.google.com by arms...@ukr.net on 11 Aug 2011 at 9:08

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Aux* methods are called only when serializing object while model.GetKey called 
before it so they don`t help much.
Any way to avoid suggested wrappers over the list/collection here?

Original comment by arms...@ukr.net on 12 Aug 2011 at 12:15

[GoogleCodeExporter]

(this is just me repeating an earlier comment, but in the correct account):

Well, it *does* - but it process them through what is, in the internal 
implementation, something called the "Aux*" methods - since there are a myriad 
of ways of writing something that looks like a "list-of-T". I will endeavour to 
ensure that WCF gets the message that these *can* be processed, though.

In the interim, a more "obvious" (to the engine) mechanism is to return a 
contract-type that *has* a list - it will spot that a mile away.

Original comment by marc.gravell on 12 Aug 2011 at 12:26

[GoogleCodeExporter]

In continuation: you miss my point; my proposal is to tweak the WCF code to 
note in advance that yes: it can serialize the list. I don't really want 
GetKey() to return >= 0 in this case (for implementation reasons) - the 
important thing, though, is that it does the correct job.

Original comment by marc.gravell on 12 Aug 2011 at 12:28

[GoogleCodeExporter]

Marc, thanks for idea. You mean that when WCF requests a serializer from me, I 
check whether the target type is a list/collection and return a serializer that 
uses Serializer.Serialize() instead model.Serialize() inside?
And on the other side I check whether the returned type is a list and I need to 
use that serializer to deserialize it?

Original comment by arms...@ukr.net on 12 Aug 2011 at 1:08

[GoogleCodeExporter]

Marc, one more question: are TypeModel.GetKey and .Serialize() thread-safe? 
I.e. can I create one instance of serializer (what actually WCF does when 
calling XmlObjectSerializer.CreateSerializer) _per type_ and use it for all 
serializations (multi thread as well) of such type?

Original comment by arms...@ukr.net on 12 Aug 2011 at 7:26

[GoogleCodeExporter]

Marc, did you have a chance to move forward on this problem 
http://stackoverflow.com/questions/6063273/is-it-possible-to-deserialize-a-priva
te-property-using-protobuf-net-in-silverli ?
It is really show stopper in Silverlight. Maybe you have an idea how I can 
implement it manually? Of course I`ll share the code changes.

Thanks.

Original comment by arms...@ukr.net on 12 Aug 2011 at 7:35

[GoogleCodeExporter]

The runtime itself stops me talking to private properties. There is nothing I 
can do about that.

Re thread-safe; yes, it is fully thread-safe - a single serializer is fine. We 
use a single serializer instance to drive the entire (multi-tenancy) 
stackexchange network (inc. stackoverflow etc). 

Original comment by marc.gravell on 12 Aug 2011 at 9:12

[GoogleCodeExporter]

I was able to get all things working, thanks!
Private properties in SL can be accessed if you add a SetPROPERTYNAME method 
into the target type because PropertyDecorator trying to resolve it prior using 
PropertyInfo. Cool.
Lists now are supported on the serializer level without changing data 
contracts. Excellent.
I`ll definitely take a hour to extract and send you this code to include into 
ProtoBuf samples/core. Very busy times now. Thank you again!

Original comment by arms...@ukr.net on 13 Aug 2011 at 11:45