Craig urges overkill, XmlSerializer sky is not falling

It's almost always Craig who coaxes me back into posting after a long absence. This time, it was this post about the perils of contract first and XmlSerializer. He was talking about the possibility of building types that serializer incorrectly and violate your contract definition. He concludes (among other things) that in .NET 1.x you should implement IXmlSerializable on every return type that you build when you start from a WSDL. That's a tall order, because when you implement IXmlSerializable, you have to build not just the emitter (which solves the problem he ran into) but also the parser. This is extreme overkill.

Craig got caught in a very particular set of circumstances. First, he started with WSDL. Then he hand-wrote his serializable types. Then he followed his preferred set of rules for ordering members of those types alphabetically. Most people who start with WSDL emit serializable types and the code generator puts the members in the right order to match the sequencing of the elements in the schema. It is technically correct that when XmlSerializer marshals a type, it does so in reflection order which is, I believe, undocumented. I suppose it could change and break a whole bunch of generated types, but it doesn't seem very likely. I certainly wouldn't lose sleep over it.

My advice for 1.x is to let the tool generate your type or, if you want to do it by hand, just put members in the same order they appear in the schema. For 2.0, use the Order property of the XmlElement attribute to make it concrete. The XSD.EXE tool has a switch to generate Order for you.