Was steuert die XML-Serialisierungsreihenfolge von partiellen C# -Klassen?

Question

Wie in Does the order of fields in C# matter? besprochen, wirkt sich die Reihenfolge der serialisierbaren Eigenschaften unter anderem auf die XmlSerializer-Ausgabe aus.

Aber wenn Felder in 2 Dateien sind (mit partiellen Klassen), weiß jemand, was tatsächlich die resultierende Reihenfolge steuert? Das heißt, welche Eigenschaften stehen an erster Stelle?

(Hintergrund: Ich frage dies, weil ich in einem Szenario, in dem eine der 2 Dateien ist automatisch generiert von Xsd, und die andere wird manuell bearbeitet. Die Test-Ausgabe unterscheidet sich auf Entwickler-Boxen vs unsere Skript Wahrscheinlich ist dies ein Nebeneffekt der verschiedenen Unterschiede im Timing und in der Geschichte des xsd-> C# -Schritts in den 2 Umgebungen.Verschiedene Möglichkeiten zur Behebung, aber ich würde gerne den Kompilierungsprozess ein wenig besser verstehen, wenn möglich .)

Answer 1

Nichts ist garantiert pro C# Spezifikation.

Answer 2

Ich habe festgestellt, dass die Verwendung des "einfachen" Ansatzes zum Erstellen eines Objekts durch Markieren von [Serializable] normalerweise nur für sehr einfache Implementierungen ausreicht.

Ich würde empfehlen, dass Sie die IXmlSerializable-Schnittstelle implementieren, die ziemlich einfach zu tun ist und Ihnen die ganze Kontrolle gibt, die Sie brauchen.

Answer 3

Hier ist, was wir durch das Update von einem bösen Fehler festgestellt:

Wir genau das gleiche Problem hatten, unsere Serialisierungsordnung nach einer Freigabe geändert hat, ohne dass die Serialisierung bezogenen Klassen zu ändern.

Wir hatten eine Hälfte einer Klasse von xsd-s generiert, und die andere Hälfte wurde von Hand gefertigt. Die Auftragsattribute waren wirkungslos. Was wir sahen, war, dass vor der Veröffentlichung die handgefertigten Teile zuerst serialisiert wurden und danach die Reihenfolge geändert wurde. Die Lösung befand sich in der Reihenfolge der Dateien in der Projektdatei, die die zwei Klassen enthielt. Es stellte sich heraus, dass der Serializer nach einem MSBuild-Build (auf unserem Build-Server) die Elemente der früheren (in der Datei csproj) ".cs" -Datei zuerst in das serialisierte XML einfügt. Das Ändern der Reihenfolge der ".cs" -Dateien in der csproj vertauschte die Reihenfolge und die generierten Teile waren nach Bedarf im XML vorhanden.

Dies ist mit der Antwort und Beobachtung von Eric Hirst oben ausgerichtet, als Umbenennen der Datei die csproj-Elemente neu geordnet (sie sind in der Regel in alphabetischer Reihenfolge). Achten Sie auch aus diesem Grund darauf, den csproj manuell zu bearbeiten.