この例外がスローされる理由の説明です。このサンプルのWindowsフォームアプリを使用して、例外を再現できます。StringCollectionタイプの「Setting」という名前の設定を追加することから始めます。[値]列のドットをクリックして、いくつかの文字列を入力します。フォームクラスコードを次のようにします。
public partial class Form1 : Form {
public Form1() {
InitializeComponent();
}
protected override void OnFormClosing(FormClosingEventArgs e) {
Properties.Settings.Default.Setting[0] = DateTime.Now.ToString();
Properties.Settings.Default.Save();
base.OnFormClosing(e);
}
}
デバッグ+例外、CLR例外の[スロー]チェックボックスをオンにします。フォームを実行して閉じると、例外がスローされたときにデバッガーが停止します。呼び出しスタックの最上位は次のようになります。
mscorlib.dll!System.Reflection.Assembly.nLoad(System.Reflection.AssemblyName fileName, string codeBase, System.Security.Policy.Evidence assemblySecurity, System.Reflection.Assembly locationHint, ref System.Threading.StackCrawlMark stackMark, bool throwOnFileNotFound, bool forIntrospection) + 0x2c bytes
mscorlib.dll!System.Reflection.Assembly.InternalLoad(System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity, ref System.Threading.StackCrawlMark stackMark, bool forIntrospection) + 0x80 bytes
mscorlib.dll!System.Reflection.Assembly.Load(System.Reflection.AssemblyName assemblyRef) + 0x1d bytes
System.Xml.dll!System.Xml.Serialization.TempAssembly.LoadGeneratedAssembly(System.Type type = {Name = "StringCollection" FullName = "System.Collections.Specialized.StringCollection"}, string defaultNamespace = null, out System.Xml.Serialization.XmlSerializerImplementation contract = null) + 0xcd bytes
System.Xml.dll!System.Xml.Serialization.XmlSerializer.XmlSerializer(System.Type type = {Name = "StringCollection" FullName = "System.Collections.Specialized.StringCollection"}, string defaultNamespace = null) + 0x105 bytes
StringCollectionクラスのXMLシリアライザーを含むアセンブリのXmlSerializerクラスハンティングを確認できます。LoadGeneratedAssemblyメソッドは、退屈なビットが削除された次のようになります。
internal static Assembly LoadGeneratedAssembly(Type type, string defaultNamespace, out XmlSerializerImplementation contract)
{
...
AssemblyName parent = GetName(type.Assembly, true);
partialName = Compiler.GetTempAssemblyName(parent, defaultNamespace);
parent.Name = partialName;
parent.CodeBase = null;
parent.CultureInfo = CultureInfo.InvariantCulture;
try
{
serializer = Assembly.Load(parent); // <=== here
}
catch (Exception exception)
{
...
}
....
}
そしてCompiler.GetTempAssemblyName（）：
internal static string GetTempAssemblyName(AssemblyName parent, string ns)
{
return (parent.Name + ".XmlSerializers" + (((ns == null) || (ns.Length == 0)) ? "" : ("." + ns.GetHashCode())));
}
この場合、このGetTempAssemblyNameは悪意のある人物です。StringCollectionクラスはSystem.dllアセンブリに存在し、メソッドは「System.XmlSerializers」という名前を生成します。このメソッドは、Sgen.exeによって生成された独自のクラスのアセンブリを見つけるように設計されています。サンプルプログラムのWindowsApplication1.XmlSerializers.dllのように。ただし、StringCollectionは.NET Frameworkのクラスであり、StringCollectionが生成するアセンブリ名は無効です。フレームワークには、実際には「System.XmlSerializers.dll」アセンブリはありません。
connect.microsoft.comでのこの動作に関するフィードバックレポートはすべて、「設計による」で閉じられています。元々の設計者は、例外を防ぐためのコストが高すぎると考え、例外をキャッチすることにしました。すべて正常に機能しますが、例外は実際にキャッチされます。[デバッグ+例外]ダイアログで[スロー]チェックボックスがオンになっているため、たまたま表示されます。
ここでは、Xmlシリアル化コードの動作を変えることはできません。System.dllアセンブリの型を単純に除外するのは簡単だったでしょうが、それは潜在的に終わりのない戦いであり、フレームワークにはさらに多くのアセンブリがあります。回避策は、StringCollectionを使用する代わりに、独自のクラスを使用して設定を格納することです。