Ein Projekt, an dem ich gerade arbeite, erfordert das Serialisieren einer Datenstruktur vor dem Herunterfahren und stellt den Zustand aus diesen serialisierten Daten wieder her, wenn es neu gestartet wird.
Letztes Jahr haben wir für .NET 1.1 gebaut und sind auf ein heikles Thema gestoßen, wo
Dieses spezielle Problem wurde durch das Sperren dieses speziellen Software-Upgrades "gelöst" und sollte jetzt kein Problem mehr darstellen, da wir auf das .NET 2.0-Framework abzielen (daher können wir unmöglich unter 1.1 laufen).
> Wie groß ist die Chance, dass sich diese Serialisierung inkompatibel zwischen 2.0 und neueren Frameworks ändern könnte? Wenn wir <supportedVersion> verwenden, um unseren Code auf 2.0.50727 zu fixieren, was sind die Chancen für Änderungen zwischen 2.0.50727.1434 und 2.0.50727.nnnn (einige zukünftige Versionen)? Die Datenstrukturen, die serialisiert werden, sind Arrays, Maps, Strings usw. aus den Standardklassenbibliotheken.
Ist außerdem garantiert, dass ein 2.0.50727-Framework auch nach weiteren .NET-Upgrades immer installiert wird? Zeiger auf Microsoft-Dokumentation willkommen.
Die Chancen stehen niedrig (aber nicht Null!), dass es zwischen den Framework-Versionen zu Änderungen kommen wird. Die Absicht wäre, dass Sie binäre Serialisierung und Remoting für die Kommunikation zwischen einem Client und einem Server mit verschiedenen Framework-Versionen verwenden könnten. Die Inkompatibilität zwischen .NET 1.x und 2.0 ist ein Fehler , für den a Patch ist verfügbar.
Allerdings hat die binäre Serialisierung andere Probleme, insbesondere eine schlechte Unterstützung für die Versionierung der Struktur, die Sie serialisieren. Aus dem von Ihnen beschriebenen Anwendungsfall ist die Xml-Serialisierung die offensichtliche Wahl: DataContractSerializer ist flexibler als XmlSerializer, wenn Sie die Abhängigkeit von .NET 3.x nicht stören.
Sie können nicht garantieren, dass .NET Framework 2.0 immer in zukünftigen Windows-Versionen installiert wird. Aber ich bin mir sicher, dass Microsoft hart arbeiten wird, um sicherzustellen, dass die meisten .NET 2.0-Anwendungen auf .NET 4.x und späteren Versionen unverändert laufen. Ich habe dafür keine Referenzen: Eine solche Verpflichtung würde in jedem Fall nur für die nächste Windows-Version (Windows 7) gelten.
Als Faustregel gilt: XML-Serialisierung sollte in der Lage sein, neue Framework-Versionen zu überleben und daher langfristig gespeichert werden, aber die binäre Serialisierung kann nicht (und sollte daher immer nur vorübergehend sein).
Welchen Serialisierer verwenden Sie? In vielerlei Hinsicht puffert ein Serializer wie XmlSerializer oder DataContractSerializer Sie aus vielen Details und bietet einfachere Erweiterungsmöglichkeiten. Irgendwann wird sicherlich eine neue CLR-Version notwendig sein - ich glaube also, niemand kann Garantien für 2.0.50727 geben; Sie sollten jedoch kurzfristig sicher sein. Und ich hoffe auf weniger brechende Veränderungen ...
[aktualisiert folgenden Hinweis auf eine andere Antwort]
Wenn Sie aus Platz- / Leistungsgründen ein binäres Format haben möchten, können Sie auch einen anderen binären Serializer verwenden. Zum Beispiel funktioniert protobuf-net für alle .NET-Varianten *, aber für das binäre Format (wird von Google unterstützt). ist plattformübergreifend kompatibel (Java, C ++, etc) - so dass es sehr portabel, schnell und klein ist.
* = Ich habe es nicht auf Mikro-Framework versucht, aber CF, Silverlight, Mono, .NET 2.0 usw. werden alle unterstützt.
Wenn Kompatibilität ein Problem darstellt, kann die ISerializable -Schnittstelle sein die Heilung, nach der Sie suchen. Diese Schnittstelle gibt Ihnen mehr Kontrolle darüber, wie Artikel serialisiert werden. Weitere Informationen finden Sie in diesem Artikel auf MSDN .
Ich muss zwei Dinge zu den anderen Antworten hinzufügen ...
Als Erstes können Sie einen benutzerdefinierten SerializationBinder verwenden Runde viele Schwierigkeiten beim Importieren von serialisierten Daten.
Zweitens halte ich es für unerlässlich, umfangreiche Unit-Tests für alle persistenten Daten zu schreiben. Ich mache immer zwei Tests:
Sie müssen nicht XML verwenden, um eine höhere Flexibilität und Versionierung zu erhalten.
Ich habe die Open-Source-Bibliothek von Simon Hewitt benutzt, siehe Optimization Serialization in. NET - Teil 2 anstelle der Standard-.NET-Serialisierung. Es bietet eine gewisse Automatisierung, aber im Wesentlichen können Sie den Datenstrom steuern, der serialisiert und deserialisiert wird. Für die Versionierung kann die (Datei-) Version zuerst und dann serialisiert werden Deserialisierungszeit Die Art und Weise, wie der Informationsstrom interpretiert wird, hängt von der Version ab.
Es ist ziemlich einfach zu tun, obwohl es wegen der expliziten etwas mühsam ist Serialisierung / Deserialisierung.
Als Bonus ist es 20-40 mal schneller und benötigt weniger Speicherplatz für große Datenmengen (ist aber in Ihrem Fall unwichtig).
Tags und Links .net serialization upgrade versions stability