WCF — Be ware of the field ordering when using DataContractSerializer
One of the less known aspect of the DataContractSerializer is its dependency on the order in which fields are serialized and deserialized.
As this article points out, the basic rules for ordering include:
- If a data contract type is a part of an inheritance hierarchy, data members of its base types are always first in the order.
- Next in order are the current type’s data members that do not have the Order property of the DataMemberAttribute attribute set, in alphabetical order.
- Next are any data members that have the Order property of the DataMemberAttribute attribute set. These are ordered by the value of the Order property first and then alphabetically if there is more than one member of a certain Order value. Order values may be skipped.
The problem is that when the inbound data is not ordered accordingly the fields which are ‘out of order’ will not be deserialized as highlighted by this StackOverflow question. Though this is unlikely to happen as the serializer will take care of the correct ordering for you, unless like jhersh you are attempting to manually create some data for test purposes.
Parting Thoughts…
Seeing as the DataContractSerializer is also dependent on the ordering of the fields in the serialized type (albeit not transparent to you and well taken care of almost all the time) I have long been tempted to try out the Protocol Buffers wrapper for .Net which are meant to be much faster and more compact because it doesn’t serialize the names of the properties unlike the DataContractSerializer.
For those of you who aren’t aware of it, protocol buffers is the binary serialization used by Google for most of its data communications. In order to use the protobuf-net serialization you need to explicitly specify the order in which your properties should be serialized:
[code lang=”csharp”]
[DataContract]
public sealed class Test1
{
[DataMember(Name=”a”, Order=1, IsRequired=true)]
public int A { get; set; }
}
[DataContract]
public sealed class Test2
{
[DataMember(Name = “b”, Order = 2, IsRequired = true)]
public string B { get; set; }
}
[DataContract]
public sealed class Test3
{
[DataMember(Name = “c”, Order = 3, IsRequired = true)]
public Test1 C { get; set; }
}
[/code]
And inject a new behaviour to the WCFmethod to use the new serializer:
[code lang=”csharp”]
[ServiceContract]
public interface IFoo
{
[OperationContract, ProtoBehavior]
Test3 Bar(Test1 value);
}
[/code]
Oh, such temptation…
References:
StackOverflow question — WCF data contract, some fields do not serialize
