問題タブ [binary-serialization]

私は次のようにオブジェクトをデシリアライズしています:

リストにあるオブジェクトには、 Serializable 属性があります。シリアル化するとエラーはスローされず、リストが空になることはありませんが、逆シリアル化するとすべてのリストが null になり、その理由がわかりません。

これをCQで回答済みとしてマークしています。使用しようとしているオブジェクトを適切にシリアル化/逆シリアル化する小さな 1 回限りのテスト アプリを作成することができましたが、まだ実稼働コードで動作させることができないようですが、それは小さなものであると思われます。行方不明です。

先週は連載にかなりの時間を費やしました。その間、BinaryFormatter または XmlSerializer を利用した多くの例を見つけました。残念ながら、私が見つけられなかったのは、2 つの違いを包括的に詳述する例ではありませんでした。

私の好奇心の起源は、BinaryFormatter がインターフェイスに直接逆シリアル化できるのに XmlSerializer ができない理由にあります。Jon Skeetは、「実行時に複数の (未知の型) にキャストする」 への回答で、インターフェイスへの直接バイナリ シリアル化の例を提供しています。Stan R.は、「 XML Object Deserialization to Interface」への回答で、XmlSerializer を使用して私の目標を達成する手段を提供してくれました。

XmlSerializer が XML を使用しているのに対し、BinaryFormatter はバイナリ シリアル化を利用していることは明らかですが、基本的な違いをより完全に理解したいと思います。どちらをいつ使用するか、およびそれぞれの長所と短所。

次のクラスのバイナリシリアル化を使用して保存されたデータがあります。

ある時点で、クラスは次のように変更されました。

これにより、古いデータの逆シリアル化で問題が発生します。

私が最初に考えたのは実装することでしたISerializableが、このクラスには多数のプロパティと、これを実装する必要のある数百の継承クラスがあります。

デシリアライズ中に現在の構造に一致するように古いデータを変更するか、古いデータをクリーンにアップグレードする方法が必要です。

タイプ DataTable のオブジェクトを SQL 2005 データベースのタイプ varbinary のフィールドに保存しました。元に戻したいのですが、型キャストできませんでした。これが私がそれを保存した方法です。

「dt」は DataTable オブジェクト インスタンスです。

次のようなクラスがあるとします。

addressを呼び出す前に、フィールドの値が存在するかどうかをテストするにはどうすればよいinfo.GetString(address)ですか?

はい、単純にヌルaddressフィールドを記述できることは理解していますが、実際の問題は、以前のバージョンのMyClassにはアドレス フィールドがなかったことです。

注:カスタム シリアライゼーションを使用するのには十分な理由があります。シングルトンとして使用されているいくつかの静的フィールドがあり、デフォルトの逆シリアル化はそれを尊重しません。

MSMQ (主に文字列) を介してネットワーク経由でオブジェクトをシリアル化するユース ケースがあります。キューからオブジェクトを読み取るときに、ユーザーがオブジェクトを XML にするつもりだったのか文字列にするつもりだったのかを判断できるようにしたいと考えています。これを行う良い方法は、タイプを確認することだけだと思っていました。XmlElement の場合は XML データになり、それ以外の場合は文字列または CDATA になります。データが有効な XML かどうかだけを確認したくない理由は、文字列としてシリアル化されるはずのデータが実際には有効な XML である場合があるためです。呼び出し元が文字列または XML への逆シリアル化を制御できるようにしたい。

XElement や XmlElement (両方ともシリアル化可能とマークされていない) のように、.NET Framework でシリアル化可能とマークされている型はありますか?

シリアル化可能としてマークされていないオブジェクトによってイベントが処理されると、シリアル化が失敗するため、イベントクラスメンバーのシリアル化を回避する必要があります。

EventクラスメンバーでNonSerialized属性を使用しようとしましたが、コンパイルに失敗します。このコード行：

次のエラーが発生します。

この宣言タイプでは属性が無効であるため、属性'NonSerializedAttribute'を'PropertyValueChanged'に適用できません。

イベントメンバーのシリアル化を回避する別の方法はありますか？

イベントが処理されない場合、これは問題ではありません。オブジェクトをシリアル化する前に、オブジェクトのクローンを作成する（そしてイベントを無視する）ことで回避できます。もっと良い方法があるかどうか疑問に思っています。

ありがとう。

バイナリ シリアル化を使用してディープ クローンされたデータ オブジェクトがあります。このデータ オブジェクトは、PriceChanged などのプロパティ変更イベントをサポートします。

PriceChanged にハンドラーを追加したとします。コードが PriceChanged をシリアル化しようとすると、ハンドラーがシリアル化可能としてマークされていないという例外がスローされます。

私の代替案:

• シリアル化の前にイベントからすべてのハンドラーを簡単に削除することはできません
• すべてのハンドラーの依存関係も再帰的にマークする必要があるため、ハンドラーをシリアル化可能としてマークしたくありません。
• PriceChanged を NonSerialized としてマークしたくありません。ハンドラーを持つ可能性のあるこのようなイベントが数十あります。EDIT：これができないもう1つの理由は、データクラス（したがってイベント）が生成され、生成コードを直接制御できないためです。理想的には、生成コードはすべてのイベントを NonSerialized としてマークするだけです。
• 理想的には、.NET がその時点でオブジェクト グラフをたどるのをやめて、それを「リーフ」にすることを望みます。では、.NET でクラス全体を NonSerialized としてマークできないのはなぜでしょうか?

--

最終的に、ハンドラーに ISerializable を実装させ、シリアル化コンストラクター/ GetDataObject メソッドで何もしないことで、この問題を回避しました。ただし、ハンドラーは依然としてシリアル化されており、すべての依存関係が null に設定されているため、それも考慮する必要がありました。

クラス全体のシリアル化を防ぐより良い方法はありますか? つまり、null 依存関係を考慮する必要がないものですか?

ビューステートに保存する必要のあるオブジェクトがある場合、オブジェクトの保存に必要なサイズを最適化するには、どのようなことができますか？明らかに、最小量のデータを格納することで必要なスペースは少なくなりますが、それ以外に、シリアル化された出力の大きさに影響を与えるクラス、プロパティ、属性などを設計する方法はありますか？

比較的複雑な (ゲーム) オブジェクト構造のファイルに状態情報を格納するための一時的なメカニズムとして、バイナリ シリアル化 (BinaryFormatter) を使用しています。ファイルが予想よりもはるかに大きくなり、データ構造に再帰参照が含まれているため、BinaryFormatter が実際に同じオブジェクトの複数のコピーを格納しているのか、それとも基本的な「オブジェクトと値の数が必要か」 " 算術はベースから外れているか、または過度のサイズがどこから来ているのか.

スタック オーバーフローを検索すると、Microsoft のバイナリ リモーティング形式の仕様を見つけることができました: http://msdn.microsoft.com/en-us/library/cc236844(PROT.10).aspx

私が見つけられないのは、binaryformatter 出力ファイルの内容を「覗く」ことができる既存のビューアーです。ファイル内のさまざまなオブジェクト タイプのオブジェクト数と合計バイト数を取得するなど。

これは私の「google-fu」が私を失敗させているに違いないと感じています（私が持っているものはほとんどありません）-誰か助けてもらえますか？これは以前に行われたに違いありませんよね??

更新：私はそれを見つけることができず、答えが得られなかったので、比較的簡単にまとめました（以下のダウンロード可能なプロジェクトへのリンク）。BinaryFormatter が同じオブジェクトの複数のコピーを保存していないことを確認できますが、かなりの数のメタデータをストリームに出力します。効率的なストレージが必要な場合は、独自のカスタム シリアル化メソッドを構築します。