It sounds to me that the root T here is the array itself, i.e.
int[] values = Serializer.Deserialize<int[]>(source);
If that is the case, then currently it uses a slightly sub-optimal path for that scenario (for the reason of: using the same code-path even on platforms that have weak meta-programming/reflection models, such as iOS). I will try to spend a few hours tidying that at some point, but in answer to your question - you should be able to avoid the issue here simply by adding a parent object:
[ProtoContract]
public class MyDataWrapper { // need a new name...
[ProtoMember(1)]
public int[] Values { get;set; }
}
and then:
int[] values = Serializer.Deserialize<MyDataWrapper>(source).Values;
This is actually fully compatible with data already serialized via Serialize<int[]>
, as long as the field-number used is 1
. One additional benefit of this approach is that if desired you could use the "packed" sub-format (only available for lists/arrays of primitives such as int); although maybe that still isn't a great idea in this case due to the large length (it may require buffering when serialising).
Additional context; "v1" here basically uses MakeGenericType to switch into to something like the above on the fly; however since this approach is not available in many of the additional platforms that "v2" targets, it uses a less elegant approach here. But now tht it is pretty stable there, I could re-add the optimised version when running on full .NET 2.0 or above.