9

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

昨年、私たちは .NET 1.1 向けにビルドしていましたが、難しい問題に遭遇しました。

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

この特定の問題は、その特定のソフトウェア アップグレードを禁止することで「解決」されました。.NET 2.0 フレームワークをターゲットにしているため (したがって、1.1 で実行できない可能性があります)、問題になることはありません。

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

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

4

6 に答える 6

7

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

ただし、バイナリ シリアライゼーションには他の問題があります。特に、シリアライズしている構造のバージョン管理のサポートが不十分です。あなたが説明したユース ケースから、Xml シリアライゼーションは明らかな選択です。

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

于 2008-10-15T07:09:45.960 に答える
4

一般的な経験則は次のとおりです。XML シリアライゼーションは新しいフレームワーク バージョンに耐えられるため、長期保存できますが、バイナリ シリアライゼーションはできません (したがって、一時的なものにすぎません)。

于 2008-10-15T06:00:17.567 に答える
3

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

[別の返信に関する注記を更新]

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

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

于 2008-10-15T05:48:30.837 に答える
2

互換性が懸念される場合は、ISerializableインターフェイスが探している解決策になる可能性があります。このインターフェイスを使用すると、アイテムをシリアル化する方法をより詳細に制御できます。詳細については、 msdn のこの記事を試してください。

于 2008-10-15T06:57:50.667 に答える
2

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

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

次に、永続化されたデータに対して広範な単体テストを作成することが必須であると考えています。私は常に、特に次の 2 つのテストを行います。

  1. 往復テスト - オブジェクトをシリアライズおよびデシリアライズして、まったく同じものを取得できますか?
  2. レガシー インポート テスト - アプリのすべてのリリース バージョンからシリアル化されたデータのバージョンがエクスポートされていることを確認します。データをインポートし、すべてが期待どおりに戻ってくることを確認します。
于 2008-10-15T08:35:21.077 に答える
0

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

Simon Hewitt のオープン ソース ライブラリを使用しました。デフォルトの .NET シリアライゼーションではなく、Optimizing Serialization in .NET - part 2を参照してください。ある程度の自動化が提供されますが、基本的には、シリアライズおよびデシリアライズされる情報のストリームを制御できます。バージョン管理では、(ファイル) バージョンを最初にシリアライズし、デシリアライズ時に情報のストリームを解釈する方法はバージョンに依存します。

明示的なシリアライゼーション/デシリアライゼーションのためにやや面倒ですが、実行するのは非常に簡単です。

おまけとして、20 ～ 40 倍高速であり、大きなデータ セットの場合に必要なスペースが少なくなります (ただし、あなたの場合は重要ではないかもしれません)。

于 2009-09-10T13:03:19.447 に答える