CODEWITHSUNDEEP
.netwcfserialization
user111013
user111013

Reputation:

WCF Disable Deserialization Order Sensitivity

I have a recurring problem when passing Serialized objects between non-.NET Clients, and .NET WCF Services.

When WCF Deserializes objects, it is strictly dependant upon the order of properties.

That is, if I define my class as: 

public class Foo 
{ 
  public int ID { get; set; } 
  public int Bar { get; set; } 
}

Then WCF Will serialize the object as as: 

<Foo>
  <Bar>123</Bar>
  <ID>456</ID>
</Foo>

Note: The properties are serialized in alphabetical order.

If you attempt to Deserialize an object which has the positions of Bar and ID swapped, WCF will treat the incorrectly positioned elements as null.

Whilst I know I can use the DataMember attribute, and force a specific ordering, I want to reduce the number of times I have to debug issues where fields are 'mysteriously' null.

So, my question is: Can you tell the WCF Deserializer to ignore the order of fields, when deserializing objects.

Upvotes: 32

Views: 17826

Answers (4)

vlabatut
vlabatut

Reputation: 307

For me, the DataContractSerializer has been my savior with .NET Framework 4.0

When referencing an old asmx web service, we had null values for all the fields that were "after" inserted new fields in the server wsdl. So whenever there were new fields added on server side, that was nullifying several values on client side. This was forcing us into updating our reference in our code to always stick to the server wsdl.

I found two solutions to make our client tolerant to new fields in the xml stream:

  • Either use an old web reference in visual studio (old client code generator for compatibility)
  • Or use a WCF classic reference, but change the serializer in the svcmap file. ClientOptions -> Serializer = "DataContractSerializer" instead of "Auto". I found out that in our case, the "Auto" value was the same as "XmlSerializer" value.

Upvotes: 0

to StackOverflow
to StackOverflow

Reputation: 124696

You can use the IsRequired property of the DataMember attribute to specify that the elements are required. In that way, instead of getting "mysterious" null value, you'll get a more explicit error message indicating that a required element is missing.

[DataContract]
public class Foo 
{ 
  [DataMember(IsRequired=true, Order=1)]
  public int ID { get; set; } 

  [DataMember(IsRequired=true, Order=2)]
  public int Bar { get; set; } 
}

What's happening in your case is:

  • The DataContract expects Bar and ID elements in that order (alphabetic because you haven't specified an explicit order).

  • It encounters an ID element without a preceding Bar element. Since Bar is not required, it simply ignores it.

  • The ID element following Bar is ignored because it is in the wrong position.

Having said that, setting IsRequired to true will only help in version 1 of your contract. Elements added in subsequent versions will normally have IsRequired set to false. MSDN has an article on data contract versioning.

Upvotes: 11

Paul Stovell
Paul Stovell

Reputation: 32715

There's an old thread on this here:

http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/a891928b-d27a-4ef2-83b3-ee407c6b9187

Looks like the only option is to swap the serializer, but then it becomes opt in which is even more annoying.

Edit: you could write your own serializer to re-order the elements and then pass it on to DataContractSerializer.

Upvotes: 7

marc_s
marc_s

Reputation: 754478

You can specify the serialization order by decorating the elements in your data contract:

[DataContract]
public class Foo 
{ 
  [DataMember(Order=1)]
  public int ID { get; set; } 

  [DataMember(Order=2)]
  public int Bar { get; set; } 
}

So you can make sure the serialization order is the same all the time. But there is no way to tell the deserializer to "forget" about the order - the point is: this is handled by means of an XML schema, and done using the <xs:sequence> element - and that does imply and require order. You cannot just turn that off, I'm afraid.

Based on that XML schema, your non-.NET clients should be able to verify whether or not their XML that they're about to send conforms to that schema - and if it doesn't because the Bar and ID element have been swapped, they shouldn't be sending that invalid XML.

Upvotes: 12

Related Questions