4

As discussed in Does the order of fields in C# matter?, the order of serializable properties affects, among other things, XmlSerializer output.

But if fields are in 2 files (using partial classes), does anyone know what in fact controls the resulting order? That is, which file's properties comes first?

(Background: I ask this because I've run into a scenario where one of the 2 files is auto-generated from xsd, and the other is manually edited. The test output is different on developer boxes vs. our scripted build box. Presumably this is a side effect of the several differences in the timing and history of the xsd->C# step in the 2 environments. Various ways to fix, but I'd like to understand the compilation process a little better if possible.)

Community
  • 1
  • 1

3 Answers3

2

Nothing is guaranteed per C# spec.

Mehrdad Afshari
  • 414,610
  • 91
  • 852
  • 789
  • Thanks Mehrdad. I'll extend your answer slightly based on my own observations. 1. The order is not guaranteed, as you say. 2. With VS 2008, the ordering is at least in part a function of file name sort order. That is, renaming the files can affect the order. -Eric –  Mar 27 '09 at 16:13
2

I've found that using the 'easy' approach to making an object by marking it [Serializable] is usually only good enough for very simple implementations.

I would recommend that you implement the IXmlSerializable interface which is pretty easy to do and gives you all the control you need.

STW
  • 44,917
  • 17
  • 105
  • 161
  • Right, we do that in places where we find we more or less have to. In this case, the benefit of easy code maintenance outweighed any need for absolute control. (When possible, our pattern is to treat .xsd as the source, autogenerate C# via xsd.exe as a pre-build step, and extend the partial classes as needed.) The "fix" that I ultimately chose in this case was to simply rename the file containing our extension to the partial class. –  Apr 21 '09 at 21:03
1

Here is what we found out through the fix of a nasty bug:

We had exactly the same problem, our serialization order has changed after a release without modifying any of the serialization related classes.

We had one half of a class generated from xsd-s, and the other half was hand-made. The order attributes were effect-less. What we saw was that before the release, the hand-made partial parts were serialized first, and after it the order changed.

The solution was in the order of the files in project file, that contained the two classes. It turned out, that after an MSBuild (on our build server) build, the serializer will put the elements of the earlier (in the csproj) ".cs" file first in the serialized XML. Changing the order of the ".cs" files in the csproj swapped the order and the generated parts were up front as needed in the XML.

This is is aligned with the answer and observation of Eric Hirst above, as renaming the file reorders the csproj's items (they are generally in alphabetical order). Watch out for editing the csproj by hand for this reason too.

vik.barca
  • 41
  • 1
  • 4