問題タブ [xmlserializer]

この XML フラグメントを含むリクエストを生成する必要がある WCF クライアントがあります。

スキーマはサーバーによって決定され、私の管理下にはありません。nullFlavor生成されたプロキシ コードには、(特に) プロパティとを含む reason 要素のクラスがありtypeCodeます。プロキシは XmlSerializer を使用します。

どうすればそのようなフラグメントを生成できますか? XmlSerializer はxsi:nil、対応するメンバーが null の場合にのみ属性を発行します。null の場合、属性として出力されるプロパティを持つことはできません!

ところで、フラグメントは、nil 要素に子要素または内部テキストを含めることはできませんが、属性を含めることができると述べている XML スキーマ インスタンス仕様に従って合法です。

ソケットを介して外部インターフェイスから受信した XML を読み込もうとしています。問題は、XML ヘッダーでエンコーディングが正しく指定されていないことです (iso-8859-1 と表示されていますが、utf-16BE です)。エンコーディングが utf-16BE であることが文書化されていますが、どうやら正しいエンコーディングを設定するのを忘れていたようです。

逆シリアル化するときにエンコーディングを無視するには、次のように StringReader を使用します。

上記は実際には問題なく動作しますが、ReadLine を呼び出してヘッダー行をスキップする部分が好きではありません。XML ヘッダーで指定されたエンコーディングをバイパスする脆弱性の低い方法はありますか?

StreamReader を使用したソリューション

StreamReader を使用することで、XML ヘッダーで指定されたエンコーディングをオーバーライドできます。XmlReaderSettings.IgnoreProcessingInstructions を指定してもしなくても、違いはありませんでした。興味深いことに、StreamReader は、Unicode のバイト順マークが見つかった場合、指定されたエンコーディングを無視します。

要点をまとめると：

• XmlReader が TextReader で初期化されている場合、XML ヘッダーのエンコーディングは無視されます。
• StringReader が使用されている場合、Unicode バイト順マークが存在すると、XmlReader は失敗します。
• StreamReader が使用されている場合、Unicode バイト順マークが StreamReader エンコーディングをオーバーライドします。
• XmlReaderSettings.IgnoreProcessingInstructions = true は、TextReader を使用する場合に違いはありません。

結論として、最も堅牢なソリューションは、StreamReader を使用することのようです。これは、存在する場合、バイト オーダー マークを使用するためです。

Uriプロパティを使用してクラスをシリアル化できません。

このプロパティをシリアル化したいと思います。これを回避する方法は何ですか？ある種のコンバーターを宣言し、URI の文字列表現を使用する必要がありますか?

一部の xml を C# のオブジェクトに逆シリアル化する際に問題が発生しました。

私が受け取るエラーは...

クラスを生成するために受け取った XSD は次のとおりです...

（中略）

インポートしようとしているファイルは次のとおりです。

（中略）

.Net が xml を逆シリアル化しようとすると、"xmlns:ast" を含む最初の行にヒットし、それに関する苦情が発生します。私が理解しているように、.Net は属性をターゲット クラスのパブリック プロパティにマップしようとします (そして、xmlns と呼ばれるものを見つけられません。または、名前空間の処理方法に問題があります。

私の逆シリアル化コードは次のようになります。

また、名前空間マネージャーを XML ドキュメントに追加するさまざまな組み合わせも試しました。

これを使用して.Netにどの名前空間を受け入れるかを伝える方法があることを理解しています。

この問題を解決するのに役立つでしょう。

--- 要求に応じてクラス スニペットで更新 (以前に含まれていたはずです) これは xsd.exe で作成されました ---

多くのフィールドを持つクラスで単純な XmlSerializer.Deserizlize() を呼び出しているときに、非常に大きなパフォーマンスの低下が発生しています。

注: 自宅で Visual Studio を使用せずにコードを書いているため、エラーが発生する可能性があります。

私のシリアル化可能なクラスはフラットで、何百ものフィールドがあります。

私のアプリケーションは入力文字列を逆シリアル化します (小さい場合でも):

32 ビット システム (または、corflags.exe で 32 ビットを強制) でアプリケーションを実行すると、コードは最初に約 1 秒かかります(一時シリアル化クラスの生成、およびすべて...)、その後は 0 に近くなります。

64 ビット システムでアプリケーションを実行すると、コードは最初は 1 分かかり、その後は 0 に近くなります。

XmlSerializer の最初の実行中に、大きなクラスの 64 ビット システムで、システムがこれほど長時間ハングする可能性があるのは何でしょうか?

現時点では、一時クラスの生成/削除、xml 名テーブルの初期化、CAS、Windows サーチ、アンチウイルス、またはサンタ クロースのせいにする必要があるかどうかはわかりません...

スポイラー

ここに私のテストがあります。私の (可能性のある) 分析ミスによって脱線したくない場合は、これを読まないでください。

• Visual Studio デバッガーからコードを実行すると、64 ビット システムでもコードが高速に実行されます。
• (まったく文書化されていない) system.diagnostic スイッチ "XmlSerialization.Compile" を追加すると、システムがシリアライゼーション一時クラスを削除するのを防ぐことができ、64 ビット システムでもコードが高速に実行されます。
• ランタイムによって作成された一時的な FooXmlSerializer クラス (プロジェクトの .cs を含む) を取得し、XmlSerializer の代わりに使用すると、64 ビット システムでもコードが高速に実行されます。
• 私のプロジェクトに.csを含め、sgen.exeで同じFooXmlSerializerクラスを作成し、XmlSerializerの代わりにそれを使用すると、64ビットシステムでもコードが高速に実行されます
• sgen.exe で同じ FooXmlSerializer クラスを作成し、私のプロジェクトで Foo.XmlSerializers.dll アセンブリを参照し、XmlSerializer の代わりにそれを使用すると、64 ビット システムでもコードの実行が遅くなります (これは私を大いに悩ませます) 。
• パフォーマンスの低下は、逆シリアル化する入力に実際に大きなクラスのフィールドが含まれている場合にのみ発生します (これも私を大いに悩ませます)

最後のポイントをさらに説明するには、クラスがある場合:

Foo の子を渡す場合のみ、デシリアライズが遅くなります。すでに逆シリアル化を実行した場合でも:

編集プロセスモニターで実行を分析したことを忘れていましたが、アプリやcsc.exe、またはフレームワーク関連のものから長時間かかるタスクは見られません。システムは、ウイルス対策、explorer.exe、Windows Search のインデックス作成 (既にそれらをオフにしようとしています) など、他の処理を実行するだけです (または、何か不足しています)。

xsd.exe ツールを使用してスキーマからクラスを生成しました

xmlns=""クラスをシリアル化すると、ルートの下のすべてに余分なものが得られます。

スキーマは次のようになります。

tag1 要素以下がルート以外の別の名前空間にある必要があることを示すスキーマが見つかりません。

シリアル化コードは次のことを行います。

xsd.exe から生成されたクラスには、ルート クラスの名前空間属性のみが含まれます。

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

XmlSerializer を使用してシリアル化し、次の出力を取得したいと思います。

どんな助けでも大歓迎です。

かなり複雑な質問ですので、よろしくお願いします。次の2つのxmlファイルは両方とも指定されたスキーマに対して検証されますが、.NetのXmlSerializerを使用して逆シリアル化を試みると、最初のファイルのみが正しく検証されます。

ただし、2番目のファイルは正しく逆シリアル化されません。以下(iso_10303_28.uos as uos1).Itemsではnullとして逆シリアル化されます。

私のデシリアライザーは基本的に次のとおりです。

uosクラスは次のとおりです。

のクラスiso_10303_28は次のとおりです。

誰かが以前にこの問題に遭遇したことがありますか？これには理由がありますか？私は何かを逃したことがありますか？修正または回避策はありますか？

スキーマと残りのコードはサイズがかなり大きいため、失敗する部分を最小限に抑えようとすると、さらに多くの問題が発生しました（この質問を参照）。ここでは貼り付けていません。ただし、必要に応じて、この問題のスキーマ、単体テスト、およびソースはhttp://code.google.com/p/ifc-dotnet/にあります。

抽象クラスから継承するクラスで構成されたツリー構造を構築するプログラムを作成していますNode。私のプログラムには、さまざまなタイプのノードが組み込まれています。ただし、より上級のユーザーが私のライブラリを参照して、独自の派生物を作成できるようにしたいと考えていますNode。これらのプラグイン ライブラリは、アプリの起動時に読み込まれますAssembly.Load()。したがってNode、アプリケーションで使用されるすべての潜在的な型は、実行時までわかりません。

さらに、これらのツリーを XML ファイルとの間でシリアライズおよびデシリアライズできるようにしたいと考えています。XMLSerializer、DataContractSerializer、および IXmlSerializable の実装について、ある程度の経験があります。通常、私は DataContractSerializer を使用します。これは、通常、IXmlSerializable を実装するよりも少ないコードで済み、XmlSerializer ではできないプライベート フィールドをシリアル化できるためです。

しかし、このプロジェクトでは、他のユーザーが私のクラスから派生したクラスを作成し、それらをシリアル化するために必要なコードや属性を追加する必要があることも考慮する必要があります。

これを考慮すると、あるシリアル化メカニズムを別のメカニズムよりも優先する必要がある理由はありますか?

各タグ間に識別情報または少なくとも改行がある XML ファイルを作成するにはどうすればよいですか?

XML の作成を処理するためにクラス XMLSerializer (Android で利用可能) を使用しています。

次に、BufferedWriter を使用して、xmlFileContents の内容を使用してファイルを作成します。ファイルは書き込まれますが、XML は識別されておらず、識別されることを望んでいます。

ありがとう。