問題タブ [netdatacontractserializer]

DataContractSerializer.NET 3.5 では、シリアル化の動作を からに切り替えるカスタム属性 ([NetDataMember] など) を作成したいと考えていNetDataContractSerializerます。

基本的に、A以下に示すようなクラスの場合

DataContractSerializerデフォルトのように動作するシリアライザーを取得したいと思いますが、NetDataContractSerializerでマークされたプロパティではオーバーライドされます[NetDataMember]。

このような動作を実現するシリアライザーを設計する方法はありますか?

コンパイル時に定義される既存のすべてのインスタンスの静的ディクショナリを保持するクラスがあります。

基本的には次のようになります。

他のフィールドがあり、クラスが派生しますが、これは問題には関係ありません。

のみidがシリアル化されます。このタイプのインスタンスが逆シリアル化されるとき、新しいインスタンスを取得する代わりに、を使用して静的フィールド（ A、、BまたはC）として作成されたインスタンスを取得したいと思います。Foo.Get(id)

これを行う簡単な方法はありますか？理解できる資料は見つかりませんでした。

NetDataContractSerializerがシリアル化されたコレクションに「nil」エントリを追加する理由を誰かが知っていますか？

例えば、

3つの追加の「JobRecord」エントリと「ねえ、ここに4つのノードがあることはわかっていますが、そのうちの1つだけが何かを意味します」という追加の要素に注意してください。

奇妙な振る舞いのようです。さて、NDCSがオブジェクトグラフを深く覗き込んでいて、シリアル化されているアイテムの数よりも大きいサイズのバッキング配列をいじっている可能性があることがわかりました（リストのバッキング配列を考えてみてください）。

それはここで何が起こっているのですか？これは、コンストラクターが処理するために作成するクラスyield return（JobRecordのソース）のアーティファクトですか？

このクラスのシリアル化は正常に機能します。ただし、フィールドを除外したい場合もあります。これは可能ですか？

フィールドを一時的に null に設定することはできません。

を使用してNetDataContractSerializerいます。オブジェクトを正常にデシリアライズした後、オブジェクトにその構築を終了するように指示する方法はありますか? 私は次のように考えています：

50,000レコードのリストです（実際にはもっとたくさんありますが、小さなものから始めましょう）。JSONファイルにシリアル化しようとしています：

悪名高いStackOverflowExceptionが発生しています。正確には：

タイプ'System.StackOverflowException'の未処理の例外がFSharp.Core.dllで発生しました

何かアドバイス？

wsHttpを使用して WCF を使用して( NetDataContractSerializer経由で) 大量のシリアル化されたオブジェクト グラフを転送する必要がある場合があります。メッセージ セキュリティを使用しており、引き続き使用したいと考えています。このセットアップを使用して、シリアライズされたオブジェクト グラフを転送したいと思います。転送しようとすると、System.InsufficientMemoryException 型の例外が表示されるようになりました。

少し調査した結果、WCF では、デフォルトで、サービス呼び出しの結果が、シリアル化されたデータを含む単一のメッセージ内に含まれており、このデータは、メッセージ全体が完全に書き込まれるまでデフォルトでサーバーにバッファリングされるようです。したがって、メモリ例外は、サーバーがバッファがいっぱいであるために割り当てることができるメモリ リソースを使い果たしているという事実によって引き起こされています。私が遭遇した 2 つの主な推奨事項は、ストリーミングまたはチャンクを使用してこの問題を解決することですが、それが何を伴うのか、また現在のセットアップ (wsHttp/NetDataContractSerializer/Message Security) でどちらの解決策も可能かどうかは明確ではありません。これまでのところ、メッセージの暗号化と復号化は部分的なメッセージではなく、データのセット全体に対して機能する必要があるため、ストリーミング メッセージ セキュリティを使用しても機能しないことを理解しています。チャンクは可能かもしれませんが、私がリストした他の制約でどのように行われるかは明確ではありません。利用可能なソリューションとその実装方法について誰かがガイダンスを提供できれば、非常に感謝しています。

私の場合、通信の両側を所有および制御し、どちらの側にも転送されるデータに共有インターフェイス パターンを使用するため、他のクライアントとの相互運用性については特に心配していません。したがって、私は、wsHttp をメッセージ セキュリティと共に使用して、NetDataContractSerializer を使用してシリアル化されたオブジェクト グラフを転送するという制約の範囲内に収まるアイデアを受け入れており、既存のサービスと周囲のインフラストラクチャを大幅に変更する必要がないソリューションを好みます。

関連リソース:

• チャンキングチャンネル
• 方法: ストリーミングを有効にする
• WCF 経由の大きな添付ファイル
• カスタム メッセージ エンコーダー
• InsufficientMemoryException の別の発見
• 非二重チャンキング チャネルが必要
• WCF と遅延実行による大きなコンテンツのストリーミング

このデータに対して実行できるあらゆるタイプの圧縮にも興味がありますが、クライアントが gzip を自動的にサポートするように、.NET 4.0 に移行できるようになったら、トランスポート レベルでこれを行うのがおそらく最善のようです。これを正しく理解していればヘッダー。

更新 (2010-06-29):

バッファリングされたメッセージが大きすぎることが問題の原因であるという結論に達した方法に関するいくつかの歴史。もともと、テスト中に以下のCommunicationExceptionを見ました。

基になる接続が閉じられました: 接続が予期せず閉じられました。

最終的に、これを実行してさらにログを記録した後、指定されたメッセージで問題を引き起こしている基になるInsufficientMemoryException例外を見つけました。

268435456 バイトのマネージ メモリ バッファの割り当てに失敗しました。使用可能なメモリ量が少ない可能性があります。

これは、次の方法に由来します。

System.ServiceModel.Diagnostics.Utility.AllocateByteArray(Int32 サイズ)

つまり、失敗は配列の割り当てに起因します。シリアル化された同じデータをディスクに書き込むと、約 146MB を占めます。それを半分に減らすと、エラーが発生しなくなりますが、バッファを壊す特定のしきい値と、それがシステムに固有なのか、それともいいえ。

更新 (2010 年 12 月 6 日):

この時点で、次の説明を求めていると思います。私の理解では、デフォルトではメッセージセキュリティを備えたWCF wsHttpでは、応答がクライアントに送り返される前にメッセージ全体（通常は返されるデータセット全体）をサーバーにバッファリングする必要があり、問題が発生します。

可能な解決策：

• データ サイズの制約 - 送信バッファの最大容量を消費しないようにするために、なんらかの形式の圧縮、エンコード、またはメソッドのようなページングを使用して返される実際のデータの制限を使用します。
• ストリーミング - WCF を介してストリーミング方式で大量のデータを送信できますが、これらの手法ではすべてのデータをバッファリングする必要があるため、これは wsHttp または MessageSecurity と互換性がありません。
• Chunking Channel - データを個別のメッセージに分割できるようにしますが、現時点では、これがサービス コントラクトの設計に及ぼす制約と、メッセージ バインディングで wsHttp を引き続き使用できるかどうかはわかりません。

返すことができるデータを制限することは、ある程度までしか機能せず、ストリーミング オプションと同様に、これらのオプションでは、WCF サービス呼び出しの外部で多くの下位レベルの作業をコーディングする必要があります。したがって、私が知る必要があるのは、単一のデータ セットをサーバー上で個別のメッセージに分割し、クライアント上でつなぎ合わせることができるようにすることで、大きなメッセージの問題を回避できる可能性のあるチャンキング チャネルの実装があるかどうかということです。これにより、既存のサービス コントラクトのインターフェイス/形状を変更する必要がなくなり、メッセージ セキュリティと wsHttp を使用しながら、各サービス実装のクライアントとサーバーの部分からプロセスがほとんど隠されます。チャンキング チャネルで、ストリームを公開するためにサービス コントラクトを書き直す必要がある場合は、必要ありません。これがストリーミング ソリューションと実際にどのように異なっているかがわかります。誰かが私のためにこれらの質問に簡単に答えることができれば、賞金を授与し、それを答えとしてマークします.

NetDataContractSerializer (または私が推測する任意のシリアライザー) を使用して、逆シリアル化中に通常はシリアル化できない型のオブジェクト作成を制御したいと思います。カスタム SerializationBinder を使用して、構築される型を制御し、カスタム ISurrogateSelector および ISerializationSurrogate を使用して、オブジェクトの状態を設定する方法を制御できます。

私ができないことは、実際に自分でオブジェクトを作成して、依存性注入などを使用できるようにすることです。問題を引き起こしているオブジェクトはオブジェクト グラフ内にあるため、シリアル化する前に編集できません。

私のコードが逆シリアル化されたオブジェクトを構築できるようにする方法はありますか?

(背景として、私は WF サンプルの XmlWorkflowInstanceStore に基づいてカスタム WF4 永続インスタンス ストアを作成しています。インターフェイスである変数を持つワークフローを作成したいのですが、具体的な型を直接構築することはできません。XmlWorkflowInstanceStore は唯一のたとえば、カスタムの永続性を見つけることができ、NetDataContractSerializer を使用してワークフローの状態をシリアル化します。)

私は AppFabric キャッシュを試していますが、取得したデータをキャッシュに保存する際に問題が発生しました。問題の根本は、AppFabric キャッシュでは、データに DataContract 属性と Datamember 属性を保存するクラスに適用する必要があるように思われることです。

その場合、これを保存するにはどうすればよいですか (簡略化されたコード):

Put を呼び出すと、次の例外が発生します。

AppFabric がキャッシュできるように IQueryable の結果をシリアル化するにはどうすればよいですか?

ありがとうございました、

リック