.NET的
AppDomain.TypeResolve事件是一个相当底层的、但又异常强大的机制，它在运行时尝试加载一个类型（Type）但常规的查找路径都失败时，提供了一个“最后一公里”的补救机会。简单来说，它让你有机会在程序即将因为找不到某个类型而崩溃之前，介入并手动告诉运行时去哪里找到它，或者如何动态生成它。
解决方案
当CLR（Common Language Runtime）需要一个特定类型，例如在反序列化对象、创建实例、或者通过反射访问成员时，它会按一套既定的规则去寻找包含该类型的程序集。如果这些常规查找（比如在GAC、应用程序基目录、或
privatePath中）都无功而返，并且此时尚未触发
AssemblyResolve事件，或者
AssemblyResolve也未能成功解析程序集，那么
AppDomain.TypeResolve事件就会被抛出来。
这个事件提供了一个钩子（hook），让开发者有机会介入这个失败的类型解析过程。你的任务是在事件处理器中，根据CLR请求的类型名称（
ResolveEventArgs.Name），找到对应的程序集，将其加载到当前的
AppDomain中，然后返回这个程序集。一旦你成功返回了包含所需类型的程序集，CLR就会从这个程序集中找到并使用该类型，从而避免抛出
TypeLoadException或
FileNotFoundException。
我个人在处理一些复杂的插件系统或者老旧代码库的迁移时，就没少跟这个事件打交道。它就像是系统在绝望边缘发出的一个求救信号，你如果能准确回应，就能力挽狂澜。它允许你实现一些非常灵活的加载策略，比如从非标准路径加载程序集，甚至在运行时根据需要动态生成代码并加载成程序集。
何时会触发AppDomain.TypeResolve事件？
这个事件的触发时机，说起来有点像“亡羊补牢”，它不是日常操作，而是当CLR的类型查找机制“碰壁”之后才会发生。
-
程序集未找到，且
AssemblyResolve未处理或处理失败： 这是最常见的情况。当CLR需要加载一个类型，但它连包含这个类型的程序集都找不到时，首先会尝试触发
AppDomain.AssemblyResolve事件。如果
AssemblyResolve事件处理器没有找到并返回正确的程序集，或者没有注册处理器，那么
TypeResolve事件就可能紧随其后被触发，作为寻找缺失类型的一个次级尝试。 程序集已加载，但类型在其中未找到： 这种情况相对少见，但确实存在。比如，你可能通过某种方式加载了一个程序集，但CLR在尝试从这个已加载的程序集中查找某个特定类型时，发现该类型并不存在。这可能是因为程序集版本不匹配、类型被重命名、或者程序集本身就是不完整的。
TypeResolve此时能给你一个机会去纠正这种“内部缺失”。 动态代码生成与加载： 在一些高级场景中，比如你需要在运行时根据用户输入或配置动态生成代码，并将其编译成一个临时的内存程序集。当你的主程序试图使用这些动态生成的类型时，CLR自然是找不到它们的，这时
TypeResolve就能让你介入，将这些动态生成的程序集提供给CLR。 序列化/反序列化时的类型绑定： 在进行跨版本或跨部署环境的序列化/反序列化时，如果序列化数据中引用的类型，在当前运行环境中所在的程序集名称、版本或公钥令牌发生了变化，CLR可能无法直接找到匹配的类型。
TypeResolve可以让你在反序列化器尝试绑定类型时，手动进行映射和纠正。
总的来说，
TypeResolve就是CLR在“找不到”类型时的最后一道防线。如果你正在构建一个高度模块化、插件化的应用，或者需要处理复杂的版本兼容性问题，理解并善用这个事件会非常有帮助。
如何有效地处理AppDomain.TypeResolve事件？
处理
AppDomain.TypeResolve事件，需要你扮演一个“侦探”的角色，根据CLR提供的线索（缺失的类型名称），找出真正的“凶手”（包含该类型的程序集）。
注册事件处理器： 首先，你需要在应用程序启动的早期，通常是
Main方法中，为
AppDomain.CurrentDomain.TypeResolve事件注册一个处理器。
AppDomain.CurrentDomain.TypeResolve += CurrentDomain_TypeResolve;
分析ResolveEventArgs
： 在事件处理器中，
ResolveEventArgs参数是你的核心信息来源。它的
Name属性包含了CLR正在尝试解析的完整类型名称（包括命名空间和程序集限定信息，例如
"MyNamespace.MyClass, MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"）。
定位并加载程序集： 这是最关键的一步。你需要根据
args.Name来判断哪个程序集包含了这个类型。 约定式加载： 如果你的插件或动态组件有固定的命名模式或存放路径，你可以解析
args.Name来推断程序集的位置。例如，如果类型名以
"MyPlugins."开头，你可能知道它在
Plugins子目录下的某个DLL中。 配置映射： 你可以维护一个配置表（比如XML文件或字典），将类型名或命名空间映射到具体的程序集路径。 动态生成： 如果类型是动态生成的，你可以在这里触发代码生成和编译过程，然后将编译后的字节数组加载为程序集（
Assembly.Load(byte[])）。 加载方式： 一旦确定了程序集路径，使用
Assembly.LoadFile(path)或
Assembly.Load(byte[])来加载它。
Assembly.LoadFile会将程序集加载到独立的加载上下文，这对于避免版本冲突有时很有用，但可能会带来类型标识问题。
Assembly.Load(byte[])则更常用于内存加载。
返回程序集： 如果你成功找到了并加载了包含该类型的程序集，你的处理器应该返回这个
Assembly对象。CLR会从你返回的程序集中查找所需的类型。
private static Assembly CurrentDomain_TypeResolve(object sender, ResolveEventArgs args)
{
Console.WriteLine($"尝试解析类型: {args.Name}");
// 示例：假设我们知道所有缺失的插件类型都在一个特定的插件目录中
if (args.Name.Contains("MyApplication.Plugins."))
{
try
{
// 从类型名中提取程序集名称（简单示例，实际可能更复杂）
string assemblyName = new AssemblyName(args.Name.Split(',')[1].Trim()).Name;
string pluginPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Plugins", $"{assemblyName}.dll");
if (File.Exists(pluginPath))
{
Assembly loadedAssembly = Assembly.LoadFile(pluginPath);
// 确保返回的程序集确实包含我们需要的类型
if (loadedAssembly.GetType(args.Name) != null)
{
Console.WriteLine($"成功通过TypeResolve加载程序集: {loadedAssembly.FullName}");
return loadedAssembly;
}
}
}
catch (Exception ex)
{
// 记录错误，但不要抛出，让CLR继续处理或抛出原始的TypeLoadException
Console.WriteLine($"在TypeResolve中加载程序集失败: {ex.Message}");
}
}
// 如果我们无法处理，返回null，CLR会继续抛出TypeLoadException
return null;
}
错误处理与性能： 你的处理器应该足够健壮，用
try-catch块包裹可能失败的操作。如果你的处理器无法解析类型，请返回
null，这样CLR会抛出其默认的
TypeLoadException。此外，由于
TypeResolve可能被频繁触发，处理器的性能至关重要。避免在其中执行耗时的操作，可以考虑缓存已解析的程序集或查找路径。
AppDomain.TypeResolve与AppDomain.AssemblyResolve有何不同？
这俩事件在功能上确实有重叠，也常常让人混淆，但它们各自解决的问题层次是不一样的。我通常把它们理解为在不同阶段的“求救信号”。
AppDomain.AssemblyResolve事件：
触发时机： 当CLR需要加载一个程序集（Assembly），但无法在标准探测路径（GAC、应用程序基目录、
privatePath等）中找到对应的
.dll文件时，这个事件就会被触发。 解决的问题： “我找不到这个程序集文件！”。它关注的是整个程序集的物理定位和加载。 处理器任务： 你的事件处理器需要找到并返回一个
Assembly对象。这个
Assembly对象通常是通过
Assembly.LoadFile()、
Assembly.LoadFrom()或
Assembly.Load(byte[])等方法加载的。 优先级： 通常在
TypeResolve之前触发。如果
AssemblyResolve成功加载了程序集，那么
TypeResolve通常就不会被触发了。
AppDomain.TypeResolve事件：
触发时机： 当CLR需要解析一个特定的类型（Type），但无法找到该类型时。这可能发生在程序集未找到（并且
AssemblyResolve未能处理）的情况下，也可能发生在程序集已经加载但CLR在其中找不到指定类型的情况下。 解决的问题： “我找不到这个类型，它可能在某个我没找到的程序集里，或者在某个我找到了的程序集里但它不在那儿！”。它关注的是特定类型的解析。 处理器任务： 你的事件处理器需要返回一个
Assembly对象，这个程序集必须包含CLR正在寻找的那个类型。CLR会从你返回的程序集中进一步查找该类型。 优先级： 通常在
AssemblyResolve之后，作为类型解析的“第二道防线”。
我的个人理解和实践体会：
在大多数情况下，如果你只是想让CLR知道去哪里找那些放在非标准位置（比如插件目录）的
.dll文件，
AppDomain.AssemblyResolve是更直接、更高效的选择。它的粒度是程序集，解决的是“整个包在哪里”的问题。
而
AppDomain.TypeResolve则更像是
AssemblyResolve的补充，或者用于更细粒度、更特殊的场景。比如，当你的程序集已经加载，但因为某种原因（比如反射操作、序列化反序列化）需要解析一个特定的类型，而这个类型在当前已加载的程序集中找不到，或者你需要在运行时动态生成类型并加载时，
TypeResolve就显得不可或缺了。它能让你在“找不到具体某个东西”时，提供一个精确的指向。
可以这样想象：
AssemblyResolve是当你问“这本书（程序集）在哪儿？”时，图书馆管理员告诉你“去三楼那个角落找”；而
TypeResolve则是在你问“这本书里的第X页（类型）在哪儿？”时，管理员说“等等，我帮你找找看，或者我给你复印一份”。
所以，在设计动态加载或插件系统时，我通常会先考虑
AssemblyResolve来处理程序集层面的查找问题。只有当遇到更复杂的类型绑定、动态生成或者程序集内类型映射问题时，才会引入
TypeResolve来提供更精细的控制。
