を使用して型（List<T>TがXmlRootAttributeでマークされたクラスであるジェネリック）をXMLにシリアル化しようとするとXmlSerializer、aFileNotFoundExceptionがスローされ（場合によっては）、シリアル化が失敗します。
XmlSerializerアプリケーションを実行しているユーザーのTempフォルダーにランダムなファイル名で一時ファイルを作成しようとしているようですが、どういうわけかファイルが削除されてしまいます。
誰かこれを見た？回避策はありますか？
Visual Studio でビルドする場合、プロジェクトのプロパティに興味深いオプションがあります。[ビルド] タブで、シリアル化アセンブリの生成 (はい、いいえ、自動) を選択できます。私の記憶が正しければ、この例外を取り除くために「はい」でこのアセンブリを生成できませんでした。しかし、オプションを「いいえ」に設定すると、ビルドがそのようなアセンブリを検索しようとしないという印象を受けたため、イライラする FileNotFound-Exception はもうありませんでした。とにかく、すでに言ったように、例外は見た目の問題です。少なくともそれが処理される場合は、それを抑制することを考えることができます (Visual Studio でデバッグ/例外を介して構成します)。
編集:オプションは特定の状況下でのみ評価されます。最終的な解決策については、この質問 (およびその回答) を参照してください。
XmlSerializerは、シリアル化/逆シリアル化を実行するコードを生成し、これを一時アセンブリに格納することによって機能します。(このアプローチは、シリアライゼーション/デシリアライゼーションの繰り返しでは優れたパフォーマンスを提供しますが、(伝統的に) 最初の実行では驚くほどひどいパフォーマンスをもたらします)
衝撃的なパフォーマンスを軽減するために、VS2005 以降 (およびそれ以前はあまり知られていない手法を使用) では、ビルド時にシリアル化アセンブリを明示的に作成し、それをメイン アセンブリと共に出荷できます。
シリアル化アセンブリを作成/出荷しない場合、フレームワークはそれを探しているときに例外をスローする傾向がありますが、通常は例外をキャッチし、オンザフライでアセンブリを構築し、物事を進めます。ただし、'break-on-throw' が設定されたデバッガーで実行している場合、FileNotFound 例外がフレームワークの奥深くでスローされるのは少し憂慮すべきことです。
FileNotFound 例外が、表示されているシリアル化の失敗に直接関連していると確信していますか? シリアル化アセンブリを明示的に含めてみましたか?
ここでの最後の可能性は、XML シリアライゼーション ランタイムに大きな問題があるということです。これらは数年前にはより一般的でしたが、まだいくつかある可能性があります. C# または VB (またはその他) のコードで完全に正当な XML シリアル化マークアップを指定すると、型の XmlSerializer を作成すると、JIT コンパイルされたシリアル化アセンブリに対して不正なコードが作成される可能性があります。コンパイルは窒息して停止し、アセンブリをロードするとスローされます。通常、ファイル名は rfuieuy267.dll などです。
また、XmlSerialization エンジンが生成した .cs コードを保持するように、XmlSerialization エンジンに伝える秘密の呪文もありましたが、それが今どうなっているのかは覚えていません。文書化されていませんでした。私は、これらの問題の 1 つをデバッグしている MS エンジニアと協力しているときに初めてそれを知りました。しかし、きっとGooglespaceで見つけることができるでしょう。