Craig remains jumpy about XmlSerializer and element order...

Craig posted a rebuttal to my earlier post. I maintain that his original advice to implement IXmlSerializable is overkill. His argument is that you're in trouble unless you “explicitly control the order of serialization of [your] web service visible types“. I agree, except that I substitute “implicit“ for “explicit“. In either .NET 1.x or 2.0, you exercise implicit control by controlling the order of the properties or fields in your type. In .NET 2.0, you can also “explicitly“ control this using the XmlElementAttribute.Order property, which is clearly a good idea. So the only thing we disagree on is whether the implicit control available in .NET 1.x is sufficient. The answer is yes, as long as you are aware of the issue and exercise due care. I've never seen this be a problem, but this is the heart of Craig's concern (Adam commented on Craig's post that he did see this problem - Adam, please fill me in with details, I want to understand what happened!). Specifically, he says “reordering type members is just too easy for a developer to do without thinking about it“. My solution is to exercise tighter control over the set of types you use for your Web service contract. If you actually write XSDs first, you solve the problem by treating the .NET types generated from your schemas the same way you would type a .obj file. If you write code first, treat those types the way you would treat any external interface that other parties consume. You don't let developers change those willy-nilly do you? One way to enforce this is to put these types in a seperate assembly that's owned by a dev-architect.