Mar 17, 2010 at 9:52 AM
Edited Mar 17, 2010 at 3:41 PM
I believe the problem here is that the default ordering of members serialized with the XmlSerializer is based on the reflection order of the members. This means that when another member is added to the data contract the likelihood of it breaking the member
ordering is reasonably high. The Order property on the XmlElementAttribute was added in .NET 2.0 to fix this very issue, and prior to that you had no real control over member ordering. The tooling for ASMX web services (Add Web Reference) was built before
.NET 2.0 introduced the Order property and was likely never updated to use the new feature. When the new tooling for WCF web services (Add Service Reference) was built it makes sense that Microsoft would start generating data contracts that utilize the new
Order property to prevent ordering issues from happening again in the future. You will find that this is now always the case for the XmlSerializer.
The advice on MSDN for data contract versioning (when schema validation is not required) is rather interesting. This particular advice applies to DataContract types:
The Order property on the DataMemberAttribute should be used to make sure that all of the newly added data members appear after the existing data members. The recommended way of doing this is as follows: None of the data members
in the first version of the data contract should have their Order property set. All of the data members added in version 2 of the data contract should have their Order property set to 2. All of the data members added in version 3 of the data contract should
have their Order set to 3, and so on. It is permissible to have more than one data member set to the same Order number.
Even though the documentation does not provide a reason for the recommendation it does make sense. When serializing DataContract types whose DataMemberAttribute does not have the Order property set, the member ordering defaults to being alphabetical. This
means that you have fixed member ordering for the first version of the data contract, even though it seems fairly implicit if you don't have prior knowledge of the behaviour. Then in the next version after setting the Order property of the new members to the
same value, they will be grouped together after the original members, and in alphabetical order within the group. In this way the ordering remains deterministic.
You will find that when generating data contract types for the DataContractSerializer, the Order property of the DataMemberAttribute is not set until the first member that is out of alphabetical order is encountered. The Order property value will then be
set to match the ordinal position of that member, and all following members will have a strictly monotonically increasing sequence for their Order property. In this regard Microsoft is not exactly following the advice described above; no doubt advice that
was determined after the WCF tooling was built and shipped.
We could add a feature to WSCF.blue that removes the Order property from the XmlElementAttribute to provide a level of compatibility with the older ASMX generated proxies. It would also make sense to add the same feature for the DataContractSerializer when
support for it is added to WSCF.blue. In this case it would not be for compatibility, but rather to allow you to more easily follow the data contract versioning advice from Microsoft.
I hope that clears things up for you.