当从父应用程序动态加载的程序集调用时，XMLSerializer 无法保存/加载？

Question

我正在为应用程序编写一个插件 dll。应用程序通过以下方式加载插件程序集：

assembly = Assembly.Load(System.IO.File.ReadAllBytes(filename)); 

当我尝试序列化/反序列化公共类时，问题就会显现出来。我将其范围缩小到序列化：

public BindingList<MyClass> MyClasses
    { get; set; }

如果我将其注释掉，就没有问题。如果我尝试序列化：

        public static void SaveSettingsFile()
        {
            try
            {
                XmlSerializer ser = new XmlSerializer(typeof(GameTimeSettings));

                TextWriter writer = new StreamWriter(SettingPath);
                ser.Serialize(writer, Settings.Instance);
                writer.Close();
            }
            catch (Exception e)
            {
                Logger.ReportException("SaveSettingsFile", e);
                Logger.ReportException("SaveSettingsFile->InnerException", e.InnerException);
            }
        }

ser.Serialize(writer, Settings.Instance) 抛出异常：

System.InvalidOperationException Msg=There is an error in XML document (0,, 0). ->
InnerException: Object reference not set to an instance of an object.

我的类有一个默认的空构造函数。我尝试过使用 sgen。在我编写的一个简单的测试台应用程序中，序列化工作正常......只有当程序集动态加载时才会出错。

此外，从这两个线程中，

http://forums.gbpvr .com/showthread.php?30384-XMLSerializer-Problems-with-Plugins , http://forums.gbpvr.com/showthread.php?32197-System.XML-Deserialization

我知道我可以将类型从 BindingList 更改为 ArrayList 并使其工作；但是，我想继续数据绑定工作，因为有很多设置需要管理。

任何意见将不胜感激。

Answer 1

到目前为止，John Saunders 的评论似乎是正确的，您可能没有初始化 MyClasses。

既然你说它与 SGen 配合得很好，你可能还想检查它是否与编译标志有关，比如尝试将其设置为发布，看看是否会改变事情。

Answer 2

很抱歉把这个从坟墓里拉出来，但我今天再次遇到了类似的问题，这是第一个谷歌结果，所以我想我会分享。

这似乎是我不久前尝试编写 MSBuild 自定义任务（基本上是一个插件）时遇到的问题的一般情况。我在 MSDN 上发布了有关它的信息论坛。

这是评论中最相关的部分，只需将 MSBuild 替换为任何具有插件架构的应用程序，并将 CruiseControl.NET 库替换为任何使用 XmlSerializer 的库：

所讨论的库是 ThoughtWork 的 CruiseControl.NET 的远程处理库，该库使用 .NET 远程处理和一些客户端激活的对象。当您尝试激活该对象时，.NET 的二进制序列化器将开始尝试找出从何处加载 ThoughtWorks.CruiseControl 程序集，以便它可以读取该对象（我们在 1.4.4SP1 中使用 ThoughtWorks.CruiseControl.Remote.dll）正在使用）问题是二进制序列化器的 GetAssembly 逻辑没有意识到 MSBuild 已经执行了一些巫术来从任意位置加载自定义程序集。

因此，它默认尝试按照 http://msdn.microsoft.com/en-us/library/yx7xezcf%28v=VS.100%29.aspx 这意味着如果没有找到它在 GAC 中将从程序启动的位置开始探测，并且由于 MSBuild 是从 %FrameworkDir%/%FrameworkVersion% 文件夹启动的，因此不太可能找到它正在寻找的程序集。

这解释了为什么您不会在控制台应用程序中看到此问题（程序集很可能位于控制台应用程序旁边）

MSDN 论坛帖子中提供的解决方案也适用于此处，基本上他们添加了一个额外的事件处理程序来尝试从已知位置进行探测，我再次引用了相关部分：

对于任何关心的人，解决方法是为 AppDomain.AssemblyResolve 事件注册一个处理程序，并注册到那里的 Assembly.LoadFrom()。

就我个人而言，这让我感到害怕，但这是我发现的唯一有效的解决方案，更多的谷歌搜索并没有向我显示 Microsoft Connect 问题，但它很可能不会被修复或者是设计使然。