什么控制 C# 部分类的 XML 序列化顺序？答案

【问题标题】：What controls XML serialization order of C# partial classes?什么控制 C# 部分类的 XML 序列化顺序？
【发布时间】：2010-10-15 19:16:54
【问题描述】：

如Does the order of fields in C# matter? 中所述，可序列化属性的顺序会影响 XmlSerializer 输出等。

但是如果字段在 2 个文件中（使用部分类），有谁知道实际上是什么控制了结果顺序？也就是说，哪个文件的属性在前？

（背景：我问这个是因为我遇到了一个场景，其中两个文件之一是从 xsd 自动生成的，另一个是手动编辑的。开发人员框与我们的脚本构建的测试输出不同框。大概这是2个环境中xsd->C#步骤的时间和历史的几个差异的副作用。各种修复方法，但如果可能的话，我想更好地理解编译过程。 )

【问题讨论】：

标签： c# sorting xsd xml-serialization partial-classes

【解决方案1】：

C# 规范没有任何保证。

【讨论】：

谢谢梅尔达德。我会根据我自己的观察稍微扩展你的答案。 1.如你所说，订单不保证。 2. 对于 VS 2008，排序至少部分是文件名排序顺序的函数。也就是说，重命名文件会影响顺序。 -埃里克

【解决方案2】：

我发现，通过将对象标记为 [Serializable] 来使用“简单”的方法来制作对象通常只适用于非常简单的实现。

我建议您实现 IXmlSerializable 接口，该接口非常容易实现并为您提供所需的所有控制。

【讨论】：

是的，我们在我们发现或多或少必须这样做的地方这样做。在这种情况下，易于代码维护的好处超过了对绝对控制的任何需求。（如果可能，我们的模式是将 .xsd 视为源，通过 xsd.exe 自动生成 C# 作为预构建步骤，并根据需要扩展部分类。）在这种情况下，我最终选择的“修复”是只需将包含我们扩展名的文件重命名为部分类。

【解决方案3】：

这是我们通过修复一个讨厌的错误发现的：

我们遇到了完全相同的问题，我们的序列化顺序在发布后发生了变化，而没有修改任何与序列化相关的类。

我们有一个类的一半是从 xsd-s 生成的，另一半是手工制作的。订单属性没有影响。我们看到的是，在发布之前，手工制作的部分零件是先序列化的，之后顺序发生了变化。

解决方案是项目文件中的文件顺序，其中包含两个类。事实证明，在 MSBuild（在我们的构建服务器上）构建之后，序列化程序会将早期（在 csproj 中）“.cs”文件的元素首先放在序列化的 XML 中。更改 csproj 中“.cs”文件的顺序交换了顺序，生成的部分在 XML 中根据需要放在前面。

这与上面 Eric Hirst 的回答和观察一致，因为重命名文件会重新排序 csproj 的项目（它们通常按字母顺序排列）。出于这个原因，也要注意手动编辑 csproj。

【讨论】：