異なるフレームワークバージョン間での.NETシリアル化の安定性

Question

私が取り組んでいるプロジェクトでは、シャットダウンする前にデータ構造をシリアル化し、再起動時にこのシリアル化されたデータから状態を復元する必要があります。

昨年、私たちは.NET 1.1向けにビルドしていたのですが、次のようなトリッキーな問題に遭遇しました

• .NET 2.0で実行されたコード
• 何らかの方法で1.1をデフォルトとして設定したソフトウェアでアップグレードした顧客
• コードは.NET 1.1で実行され、保存された状態をデシリアライズできませんでした

この特定の問題は<！> quot; resolved <！> quot;特定のソフトウェアのアップグレードを禁止することで、.NET 2.0フレームワークをターゲットにしているので問題になりません（そのため、1.1では実行できません）。

このシリアル化が2.0と新しいフレームワークの間で再び非互換に変更される可能性はありますか？ <supportedVersion>を使用してコードを2.0.50727に修正する場合、2.0.50727.1434と2.0.50727.nnnn（将来のリリース）の間で変更される可能性はありますか？シリアル化されるデータ構造は、標準クラスライブラリの配列、マップ、文字列などです。

さらに、さらに.NETをアップグレードした後でも2.0.50727フレームワークが常にインストールされることが保証されていますか？ Microsoftのドキュメントへのポインタを歓迎します。

Answer 1

フレームワークのバージョン間で変更が行われる可能性は低い（ゼロではない！）。意図は、クライアントと異なるフレームワークバージョンを実行しているサーバーとの間で通信するために、バイナリシリアル化とリモート処理を使用できるようにすることです。 .NET 1.xと2.0の非互換性バグパッチが入手可能です。

ただし、バイナリシリアル化には他の問題があります。特に、シリアル化する構造のバージョン管理のサポートが不十分です。説明したユースケースから、Xmlシリアル化は明らかな選択です。.NET3.xへの依存を気にしない場合、DataContractSerializerはXmlSerializerよりも柔軟です。

将来のバージョンのWindowsに.NET framework 2.0が常にインストールされることを保証することはできません。しかし、Microsoftは、ほとんどの.NET 2.0アプリが.NET 4.x以降のバージョンで変更なしで実行されるように一生懸命働くと確信しています。これに関する言及はありません。そのようなコミットメントは、いずれにしても、Windowsの次のバージョン（Windows 7）にのみ実際に適用されます。

Answer 2

大まかな原則は次のとおりです。XMLシリアル化は新しいフレームワークバージョンに耐えることができるため、長期間保存できますが、バイナリシリアル化はできません（したがって、一時的である必要があります）。

Answer 3

どのシリアライザを使用していますか？多くの点で、XmlSerializerやDataContractSerializerなどのシリアライザーは、多くの詳細からユーザーをバッファリングし、より単純な拡張オプションを提供します。 ある時点で、新しいCLRバージョンが間違いなく必要になります。だから、2.0.50727について誰も保証できないと思います。ただし、短期的には安全である必要があります。そして、私はより少ない破壊的な変更を望みます...

[別の返信に関する次のメモを更新]

スペース/パフォーマンス上の理由でバイナリ形式が必要な場合は、別のバイナリシリアライザを使用することもできます。たとえば、 protobuf-net はすべての.NETバリアント*で機能しますが、バイナリ（Googleが提案した）形式は、クロスプラットフォーム互換（Java、C ++など）であり、非常に移植性が高く、高速で、小型です。

* =マイクロフレームワークでは試していませんが、CF、Silverlight、Mono、.NET 2.0などはすべてサポートされています。

Answer 4

互換性が懸念される場合、 ISerializable インターフェースはあなたが探している治療法かもしれません。このインターフェイスにより、アイテムのシリアル化方法をより詳細に制御できます。詳細については、 msdnの記事をご覧ください。

Answer 5

他の回答に追加するものが2つあります...

まず、カスタム SerializationBinder を使用すると、従来のシリアル化されたデータをインポートする際に多くの問題を回避できます。

第二に、永続化されたデータに対して広範な単体テストを書くことは必須だと思います。特に2つのテストを常に実行します。

1. ラウンドトリップテスト-オブジェクトをシリアライズおよびデシリアライズして、まったく同じものを取得できますか？
2. レガシーインポートテスト-アプリのすべてのリリースバージョンからエクスポートされたシリアル化されたデータのバージョンがあることを確認します。データをインポートし、すべてが期待どおりに戻ってくることを確認します。

Answer 6

より高い柔軟性とバージョン管理を得るためにXMLを使用する必要はありません。

Simon Hewittのオープンソースライブラリを使用しました。 .NETでのシリアル化の最適化-パート2 デフォルトの.NETシリアル化の代わり。ある程度の自動化を提供しますが、基本的に、シリアル化および非シリアル化される情報のストリームを制御できます。バージョン管理では、（ファイル）バージョンを最初にシリアル化できます。 シリアル化解除時間は、情報のストリームが解釈される方法がバージョンに依存します。

これは非常に簡単ですが、明示的であるため多少面倒です シリアライゼーション/デシリアライゼーション。

おまけとして、20〜40倍高速で、大きなデータセットのスペースを取りません（ただし、重要でない場合があります）。