問題タブ [datacontractserializer]

VB.NET (Visual Studio 2008 を使用) では、私の WCF サービスには次のようなインターフェイスがあります。

最近、同様のコードを持つ 2 つのプロジェクトを、wsHttpBinding ではなく basicHttpBinding を使用するように変更しました。すべてがサービス側でうまくコンパイルされます。次に、クライアント アプリで [Update Service Reference] を選択します。あるプロジェクトでは、結果の reference.vb は正しいように見えます。各メソッドの単純なラッパーを使用して 100 行未満です。ただし、他の例では、結果として得られる reference.vb は、サービスが何であるかを理解できないようです。次のような1000行を超えるreference.vbを取得します。

生成されたコードは、実際のサービス インターフェイスについて何も知らないかのようです。これをトラブルシューティングする方法はありますか？前もって感謝します。

編集: サーバーが XmlSerializer ではなく DataContractSerializer を使用できることを確認する必要があるようです: http://blogs.msdn.com/sonuarora/archive/2007/06/16/contract-generation-from-wsdl-を参照してくださいxml-schema-datacontractserializer-vs-xmlserializer.aspx . 私のコード (おそらく Class Thing) で DataContractSerializer の制限に違反しているものを特定する方法を知っている人はいますか?

私は安らかなサービスをアップグレードしており、現在 DataContractSerializer を使用して応答を出力しています。以前のバージョンでは、XmlSerializer を使用したカスタム シリアル化を使用していました。そのバージョンでは属性を多く使用していましたが、DCS ではまったく使用しなかったため、gzip で圧縮した場合、新しい応答サイズは以前のバージョンのサイズの 1.5 倍になっています。(または、圧縮されていない場合は約 3 倍のサイズ)。

私の質問は、DCS が本当に XmlSerializer よりも高速でスケーラブルなソリューションになるかどうかです。

次のコードを使用してオブジェクトをシリアル化します。

残念ながら、（LINQ to SQLを使用して）データベースに保存してからデータベースにクエリを実行すると、文字列は疑問符で始まるように見えます。

どうすればそれを取り除くことができますか？次を使用して逆シリアル化しようとすると、次のようになります。

次の例外が発生します。

"1行目の位置1にエラーがあります。名前空間' http://schemas.microsoft.com/2003/10/Serialization/ 'から要素'anyType'が必要です。..名前''、名前空間''の'Text'が見つかりました。"

messageSerializer使用の実装は次のDataContractSerializerとおりです。

私は 3.5 SP1 プロジェクト、Silverlight 3 クライアントによる消費に限定された WCF サービスを持っています。ビジネス要件のため、WCF 側で SQL Server を介してハイドレートされ、Silverlight クライアントに送信される大きなオブジェクト グラフを操作する必要があります。それらは深く、2 つのコレクション プロパティを持つクラスがあり、コレクション内の各アイテムにはコレクションが含まれている場合があります。基本的な設計は、私が継承したものであり、短期的には動作する必要があります。私たちはどれくらい大きく話しているのですか？一度シリアル化された 250 項目の最上位コレクションの例は、変更 (httpBinding および DataContractSerializer) を使用せずにネットワークに到達すると 14 MB になります。250個のアイテムは小さく、私たちが直面している要件では、10個で作業できる必要があります。私の限られた数学スキルを与えられた000以上のアイテムは、ワイヤーを横切って引っ張るのに500MBをはるかに超えています. 公園を散歩することはできません - 実際、公園を散歩することはできます。

そのため、検討していることはいくつかあります。1 つは、DataContractSerializer から離れて XmlSerializer を使用することです。これにより、これらのプロパティの多くを属性に移動し、ペイロード サイズを削減できます。Binary Xml バインディングも検討しています。

私の質問はこれです、あなたならどうしますか？IIS 圧縮はここで役割を果たすことができますか? DCS から離れるのは悪い考えですか? より良いテクニックはありますか？パドルなしで小川を上っていますか？

私は、mvc サイトを介してシリアル化されたいくつかのオブジェクトを取得し、xml、json などを介して物を返すことに取り組んでおり、空の要素を送信しないための最良の方法を探しています。

完璧な世界では、単に EmitDefaultValue:=False を DataContract の DataMembers にアタッチするだけで十分ですが、状況によってはうまくいきません。

String のデフォルトは Nothing ですが、Nothing または String.Empty の場合はシリアル化したくありません。リストとコレクションについても同様です。それらがNothingの場合、またはカウントが0で空の場合、それらをシリアル化したくありません。

あまりきれいではないオプションがいくつかあるようです。

1. XmlTextWriter自分自身をバッファリングして空の要素をドロップするカスタム
2. オブジェクトがシリアル化される前に、Empty を Nothing に、Count-0 を Nothing に設定して、prop を循環します。
3. 空の要素を削除する XSLT
4. 途中で出力文字列を正規表現する

これらはどれも悪いことのように思えます。そこに他のトリックはありますか？

I'm looking for a way to persist Silverlight objects to a user's PC, then re-hydrate them so the user can finish editing them.

Serialising with DataContractSerializer and persisting to IsolatedStorageFile works fine. However, deserialising causes a problem. Here's the code that causes the failure:

The deserialiser calls the property setter, which in turn throws an exception and aborts the deserialisation.

I've tried explicitly applying DataContract/DataMember/IgnoreDataMember attributes, but then it doesn't play nicely with private fields:

System.Security.SecurityException occurred Message="The data contract type 'Trident.Model.Journey.JourneyApplication' cannot be serialized because the member '_TravellerSavingsAmount' is not public. Making the member public will fix this error. Alternatively, you can make it internal, and use the InternalsVisibleToAttribute attribute on your assembly in order to enable serialization of internal members - see documentation for more details. Be aware that doing so has certain security implications."

How can I bypass the property setters during deserialisation?

I'd like to keep my classes focused on the domain, and not too polluted with infrastructure concerns.

パフォーマンス チューニングのため、必要なプロパティのみを返したいと思います。可能性/回避策はありますか? 理解するための疑似/サンプルコード:

そしてサービス：

デシリアライズする場合、DataContractSerializerは、要素名が一致するだけでなく、他の要素に対して特定の順序である必要があります。

私のアプリケーションは、すべてのフィールドをその名前で一意に識別できるようになっています。したがって、XMLファイルに要素を任意の順序で含めることができ、デシリアライザーが引き続き機能するようにしたいと思います。

このようなDataContractを設定することは可能ですか？

データメンバーの順序の導入段落は、順序がオプションで強制されることを示唆していますが、実際にそれをオプションにする方法を見つけていません。

フォローアップの質問：DataContractSerializerを使用した単純なデータファイルのバージョン管理

Data Contract Versioningを読んだ後、それがすべてではないという結論に達しました。たとえば、以前は ValueA があり、新しいバージョンでは ValueB と呼ばれ、別の型になっている場合、ValueA を ValueB に変換する必要がある場合はどうなるでしょうか。

これを支援するために使用できるコールバックがいくつかありますが、フォーマットが長期間にわたって頻繁に変更されることが予想される場合、それはあまり保守可能なソリューションのようには見えません。

私たちが解決した解決策は、「バージョンごとに保存」フィールドを保持し、ファイルのロード時に、必要に応じて古いバージョンに固有の変換ルーチンを呼び出すことです。これらの変換ルーチンは、古いデータの XML を新しいデータの XML に変換する方法を知っています。

ただし、結局のところ、DataContractSerializes では、要素の順序が期待どおりである必要があります。これは、変換プロセスが要素を正確に正しい場所に挿入することを認識している必要があることを意味します。継承を考慮すると、既知の名前を持つ要素を単純に追加するよりも、これははるかに困難です。継承では、この新しいフィールドの隣に常に単一のフィールドがないという理由だけで、どのフィールドAddBeforeSelfもAddAfterSelf 確実に継承することはできません。

DataContractSerializer が非常に厳密になった理由はさておき、これを回避する方法を提案していただけますか? おそらく、非常に古いデータ コントラクトとの下位互換性を維持する方法に関する優れた記事であり、100 回目の破壊的変更をフォーマットに加えた時点で扱いにくくなることはありません。

この記事には追加のガイドラインがいくつかありますが、これは別の目的で書かれたに違いありません。たとえば、古いデータ メンバーを永遠に放置しておくことはできません (ポイント 9)。そのような記事のほとんどは、データをファイルに保存するのではなく、通信プロトコルの観点から書かれているようです。

wsHttpBindingWCF サービスによって ( を使用して) 公開され、XML にシリアル化されるオブジェクトがいくつかあります。以下はそのうちの 1 つの抜粋です。

ご覧のとおり、多くのコレクションがあり、含まれているオブジェクトの中には、その下にさらに子オブジェクトがあるものがあります。これを本番データに対して実行すると、ほとんどの Person レコードは問題ありませんが、非常に大きなシリアル化されたメッセージ (たとえば、500 KB を超える) に変換されるものがあることがわかります。

ここで、オブジェクト グラフの刈り込みを開始する必要があると思いますが、シリアル化されたメッセージに最も貢献しているデータのビットを見つけたいと思います。たとえば、それはAddressオブジェクトのリストですか、それともInternationalExperienceオブジェクト内のデータの一部ですか。

送信されている XML メッセージをキャプチャして分析し、最も多くのスペースを占めているものを特定できるツールを知っていますか?