C# DLL地狱场景下XmlSerializers程序集加载失败问题求助

两个反常现象的本质原因可以逐一对应：

• 触发主程序/DLL1中代码的核心逻辑：异常触发点在Application_Server.Communication.Messagess.Message.ToString()方法内，代码中base.GetType()返回的是消息实例的真实运行时类型，而非定义在主程序中的Message基类。调试DLL2时触发ToString()的对象是DLL2中继承自Message的子类实例，序列化逻辑需要扫描DLL2内的类型定义，这段执行路径是调试DLL1时完全不会走到的——调试DLL1时序列化的都是DLL1自身定义的Message子类，和DLL2的类型无交集。
• 找不到Application_Server.XmlSerializers的异常本身是XmlSerializer的正常流程：.NET的XmlSerializer初始化时，默认会先尝试加载预编译的序列化程序集（命名规则为[对应程序集名].XmlSerializers.dll，由SGEN工具提前生成），如果找不到该文件，会自动捕获FileNotFoundException，回退到运行时动态生成序列化代码的逻辑，正常运行时用户完全感知不到这个过程。
  调试DLL2时异常直接弹出，核心是两个项目的调试配置不一致：
  • 大概率是Visual Studio异常设置中开启了System.IO.FileNotFoundException的「引发时中断」，调试DLL1时要么工作目录下刚好存在该XmlSerializers文件，要么配置未触发中断；
  • 另一种常见情况是DLL2的调试工作目录配置错误：配置外部启动程序时没有手动指定工作目录，默认使用项目自身的bin\Debug路径，CLR在该路径下找不到预生成序列化程序集，加上调试器加载了DLL2的符号，本应被框架内部捕获的异常直接中断到了调试器。
    你提到的FixedAssemblyInfo.cs、AssemblyInfo_Orig.cs因为未被项目引用，不会直接导致问题，但需要注意.csproj项目文件内可能残留版本修改相关的配置节点，这类节点有时不会显示在可视化属性页中，Git回滚时可能有遗漏。

按优先级依次排查即可，无需多余操作：

1. 先修正调试配置，排除误中断问题：
   • 打开VS的「调试-窗口-异常设置」，找到System.IO.FileNotFoundException，取消勾选「引发时中断」，仅保留「用户未处理时中断」选项；
   • 打开DLL2项目属性的「调试」页，将工作目录配置为和DLL1完全一致的值，要么指向Application_Server.exe所在目录，要么指向存放所有输出DLL的Modules目录。
2. 配置修改完成后直接按F5继续运行，如果程序可以正常执行、序列化输出结果符合预期，说明该异常完全是调试器的中断误报，不影响实际业务逻辑，不需要额外处理。
3. 如果继续运行后程序仍然崩溃、异常未被框架捕获，再执行以下清理检查：
   • 删除整个解决方案下所有项目的bin、obj文件夹，直接删除那两个未被引用的冗余cs文件，全量重新编译整个解决方案；
   • 用文本编辑器打开DLL1、DLL2、Application_Server三个项目的.csproj文件，查找<GenerateSerializationAssemblies>节点，将三个项目的该节点值统一为Auto或Off，不要出现部分项目开启、部分关闭的情况；如果不需要预编译序列化程序集优化启动速度，直接统一设为Off，可以彻底杜绝这类探测序列化程序集的异常；
   • 检查Application_Server.exe所在目录、Modules目录下是否存在旧版本的DLL1、DLL2残留文件，避免CLR加载到错误版本的程序集导致类型匹配失败。
4. 如果确实需要使用预编译序列化程序集提升启动性能，编译主程序项目后，将生成的Application_Server.XmlSerializers.dll同时拷贝到exe所在目录和Modules目录即可。

内容的提问来源于stack exchange，提问作者Dominique