2

I have a RESTful WCF application that makes use of custom classes as service method parameters. These classes are decorated with the [DataContract] attribute and each of their properties is decorated with the [DataMember] attribute.

The deserializer works consistent with the following "Data Member Order" page at MSDN: http://msdn.microsoft.com/en-us/library/ms729813.aspx.

That is, it expects the elements in XML formatted input data to follow the order so described. In fact, if one of the elements is out of order, after deserialization it does not have the submitted value but rather is null.

Is there a good way to allow the calling program to order the xml elements freely (i.e., in any order) and to have the deserialization come out right for every ordering of the elements?

Ralph McArthur
  • 385
  • 3
  • 10
  • I realise this question is rather old, but here's a subsequent similarly themed question - http://stackoverflow.com/questions/1727682/wcf-disable-deserialization-order-sensitivity – Reddog Apr 11 '12 at 22:03
  • Possible duplicate of [WCF Datacontract, some fields do not deserialize](https://stackoverflow.com/questions/2519240/wcf-datacontract-some-fields-do-not-deserialize) – Vlad Oct 26 '17 at 06:55
  • https://stackoverflow.com/questions/76970489/solving-the-wcf-datacontract-datamember-order-deserialization-problem – golfalot Aug 24 '23 at 16:35

1 Answers1

2

Most XML does not permit elements to be entered in arbitrary order. There's no good reason to permit this, as far as I know.

The Data Contract Serializer does not support this at all. It would add overhead, and provide no value.

Why can't your callers just send the correct XML?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • John, thanks for your answer. You said "the Data Contract Serializer does not support this at all." Can you point me to Microsoft documentation that says this directly, or did you put it together from various sources? – Ralph McArthur Aug 12 '09 at 23:49
  • @Ralph: you said it yourself: "it expects the elements in XML formatted input data to follow the order so described". Also, the various write-ups over the years on the differences between data contract serialization and XML serialization have made it clear data contract serialization is meant to be fast and simple. Choices are not "simple", and they add no value. – John Saunders Aug 13 '09 at 02:30
  • @Ralph: Please update your question to say why you want to do this. Why can't your callers just send the correct XML? – John Saunders Aug 13 '09 at 02:31
  • @John: my callers can, in fact, "send the correct XML." I was pursuing the plausibility of meeting a requirement that came not from them. What I read about the Data Contract Serializer is for sure the default behavior. I was trying to nail down whether it is the only behavior. I accept that following order is the normal way of using XML, and I am marking your answer as the solution. Thanks again. – Ralph McArthur Aug 13 '09 at 14:38
  • 1
    @Ralph: I once had a manager ask me the same question. In my case, looking at him like he was both crazy and stupid solved the problem. – John Saunders Aug 13 '09 at 14:42
  • "Most XML does not permit elements to be entered in arbitrary order" this is not really true. Lots of Xml formats don't care about order. – Ben Jun 10 '16 at 11:29
  • @ben "lots of" is fewer than "most". There's nothing "wrong" with such formats, you just don't use the Data Contract Serialized to process them. – John Saunders Jun 10 '16 at 14:48
  • "Lots of" may or may not be fewer than "most", but even so "lots of" is certainly a "good reason to permit this" - speaking as someone who has just spent several hours chasing down a bug caused by assuming order doesn't matter, because why would order matter when you have names... – Ben Jun 10 '16 at 14:59
  • 1
    There are two types of developers, those who make assumptions, and liars. So take your snark and do something more enjoyable with it. – Ben Jun 10 '16 at 19:51
  • @ben I never said or implied that I don't make assumptions. I simply hope you've now learned why that can be a bad thing. – John Saunders Jun 10 '16 at 20:22
  • 1
    Your answer is sarcastic, insulting, and other than the words "The Data Contract Serializer does not support this", the remainder is wrong. Your comments are the same. – Ben Jun 10 '16 at 20:39