問題タブ [datacontractserializer]

CastleDynamicProxyを使用して汎用IPropertyChangedNotifierを実装しました。ここでは、プロキシオブジェクトでセッター呼び出しをインターセプトして、ドメインオブジェクトのセッターでPropertyChangedイベントを発生させる必要がないようにします。

目的は、これらのプロキシオブジェクトを使用して、silevrlightアプリケーションでUIをバインドすることでした。

問題は、プロキシオブジェクトに[DataContract]がないために、WCFサービス呼び出しでプロキシオブジェクトのシリアル化が失敗することです。この問題を回避するには、インターセプターにインスタンスのコピーを保持し、このオブジェクトをシリアル化のために送信する必要がありました。IPropertyChangedNotifier

その結果、コードが複雑になり、デバッグや理解が困難になりました。WCFのシリアル化の問題を解決して、サービス呼び出しでプロキシを送信するときに基本クラス（インスタンス）の[DataContract]属性を使用するようにシリアライザーに指示する簡単な方法はありますか。

与えられたクラス:

WireShark は、WCF TCP バインディングを介して送信された場合、メッセージのエンコードがバイナリであることを示しています (印刷可能な文字のみですが、アイデアは得られます)。

ChangedFielda.I..a.V....e:double..e http://www.w3.org/2001/XMLSchema.s.....a.

しかし、このタイプのインスタンスを次のようにシリアル化すると...

...その後、ストリームには次のような SOAP XML が含まれます。

私の質問は、自分のコードでこのバイナリ表現を生成するように制御するにはどうすればよいですか?DataContractSerializer

余談として：

ご覧のとおり、objectプロパティの型をエンコードする必要があるため (つまり URI)、メッセージが肥大化しています。これを変更して、カスタム バイナリ エンコーディングを使用します。私のシナリオでは、フィールド ID によって型が決まります (この場合はdouble)。

1 つの操作メソッドと、要求/応答のタイプのペアを定義した単純なエコー サービスがあります。

データ型:

EchoRequest のインスタンスで Message.CreateMessage() を呼び出すと、次のようになります。

...まさに私が欲しいものです。ただし、次のように、メッセージ本文が別の XML 要素でさらにラップされることをサービスが想定しているようです。

更新: マークの返信のおかげで、リクエスト/レスポンス タイプで DataContract の代わりに MessageContract を調査しました。これは私が望むものに近いようですが、今は行き過ぎており、外側の型要素「EchoRequest」を期待していません。

どういうわけか Message.CreateMessage が間違いなく正しい XML を生成するように見えるため、これは紛らわしいので、サービスが受け入れるように構成したいデフォルトのシリアライゼーションを使用しているようです。Message.CreateMessage の仕組みを誤解しているだけですか?

WCF でメッセージ コントラクトとして使用する次の型があります。

svcutil.exeを使用してこのタイプのプロキシを生成すると、それをホストするサービスと通信できるクライアントが得られ、要素の XML 名前空間はメッセージ コントラクト属性に従って正しくなります。

そのインスタンスで使用すると、名前空間はデフォルト ( http://schemas.datacontract.org/2004/07/.. .)Message.CreateMessage(...)に戻ります。のインスタンスを使用すると、同じことが起こります。名前空間をコンストラクターに渡そうとすると、ラッパーのみが名前空間に含まれます。DataContractSerializerDataContractSerializer

ここで、「データ」は次のとおりです。

が属性DataContractSerializerを無視しているように見えるのはなぜですか? svcutilMessageContractはどのようにこの作業を行うのですか?

実行中に XML ドキュメントを繰り返しシリアル化および逆シリアル化する必要がある Windows サービス アプリケーションを作成しています。コンパイル時に不明なジェネリック型をシリアル化および逆シリアル化する必要があるため (シリアル化/逆シリアル化する必要がある型の数が先験的にわかりません)、キャッシュを保持するのが良い考えかどうかを知りたいですオブジェクトをシリアル化および逆シリアル化するためにインスタンス化します。

XmlSerializer クラス インスタンスは内部でメモリ内に動的アセンブリを作成し、メモリ内で動的に作成されたアセンブリはガベージ コレクションされないため、キャッシュすることをお勧めします。

DataContractSerializer は軽量コード生成に依存していると読みましたが、その詳細についてはよくわかりません。そのため、この質問をしているのですが、必要に応じて DataContractSerializer インスタンスをインスタンス化すると、XmlSerializer のようにメモリ リークが発生することを理解する必要がありますか?

内部プロパティをシリアル化できるように、XmlSerializer の代わりに DataContractSerializer を使用することにしました。

私は既知のタイプに関する多くの記事を読みましたが、私の例はうまくいくはずです。しかし、そうではありません。デシリアライズで次の例外が発生しますが、その理由がわかりません。

1行目の位置2にエラーがあります。名前空間' http://schemas.datacontract.org/2004/07/ConsoleApplication2 'から要素'A'が必要です。..名前'C'、名前空間' http：//schemasの'要素'が見つかりました。 .datacontract.org / 2004/07 /ConsoleApplication2 '。

私は何が欠けていますか？

私は WCF REST サービスを作成するのが初めてなので、ここで間違ったことをしている場合は教えてください。

次の DataContract が定義された、WCF を使用して開発された REST ベースのサービスがあります。

クライアント アプリケーションで、HttpWebRequest オブジェクトを使用して (このデータ コントラクトを使用する) サービスに POST しようとしていますDataContractSerializer(typeof(MessagingWS.Email))。 ...」をクライアント アプリケーションの MessagingWS として)。いずれにせよ、これにより次の出力が生成され、POST を試行したときにサービスから戻ってくる 400 - Bad Request が生成されます。

そのため、すべての要素に「フィールド」が追加されてしまい、それらは DataContract で指定した順序ではありません (デフォルトの順序を想定しています)。誰かがここで何が起こっているのか教えてもらえますか?もし私が不可能なことを達成しようとしているのなら?

DataContract クラスをサーバーからクライアントにコピーしたとき (そしてそれを別の名前空間 - Messaging2 に含めたとき) DataContractSerializer(typeof(Messaging2.Email))、. これは私が本当にやるべき方法ですか？うまくいくようですが、「サービス参照の追加...」を実行した後にクライアント側で取得したクラスを使用できるはずです。

どんな助けでも大歓迎です - ありがとう!

私はこのクラスを持っています：

HashSet から継承するため、ISerializable を実装する必要があるため、保護されたコンストラクターと GetObjectData メソッドが必要です。以前、このクラスを BinaryFormatter で正常にシリアライズおよびデシリアライズしました。

シリアライザーによって生成された出力を検査できるようにしたいので、DataContractSerializer に切り替えたいと思います。

私はこのテストを書きました：

Name プロパティが null であるため、テストは失敗します。（ただし、整数は正しく（逆）シリアル化されています）何が起こっているのですか？

編集:名前バッキングフィールドが非公開であることとは関係ありません。公開しても結果は同じです。