.NET的
AssemblyDependencyResolver主要通过解析应用程序的
.deps.json和
.runtimeconfig.json文件来定位和加载程序集（DLLs），它为.NET Core及后续版本提供了一种强大且可预测的依赖项解析机制，尤其在处理复杂的插件系统或隔离组件时显得尤为重要。
解决方案
在我看来，
AssemblyDependencyResolver是.NET Core生态系统里一个挺有意思的幕后英雄。它解决的核心问题，就是运行时如何找到那些应用程序需要但又不在GAC（全局程序集缓存，.NET Framework时代的概念）里的DLLs。它的工作方式说起来也挺直接：它会读取应用程序构建时生成的
.deps.json文件。这个文件，你可以把它想象成一份详细的“地图”，里面记录了你的应用程序所有直接和间接的依赖项，包括它们的版本、哈希值，以及最重要的——它们在部署目录中的相对路径。
当运行时需要加载一个特定的程序集时，
AssemblyDependencyResolver会利用这份地图。它首先会检查这个程序集是否在
.deps.json中被列为依赖项。如果找到了，它就能准确地知道这个DLL应该在哪里。它还会考虑
.runtimeconfig.json文件，这个文件包含了运行时的一些配置信息，比如目标框架版本、是否允许版本回滚等，这些都会影响到它如何选择合适的共享框架（如
Microsoft.NETCore.App）中的程序集。
更进一步，
AssemblyDependencyResolver还会构建一系列“探测路径”（probing paths）。这些路径通常包括应用程序的基目录、通过
.deps.json解析出的特定于包的子目录，以及共享框架的安装路径。当一个程序集被请求加载时，它会按照这些路径去查找对应的DLL文件。这种机制确保了即使应用程序是自包含部署（所有依赖都打包在一起），还是依赖于共享框架，
AssemblyDependencyResolver都能高效且准确地找到所需的程序集。它让依赖项的解析变得高度可预测，大大降低了“DLL Hell”的风险，特别是当多个组件或插件需要加载不同版本的同一个库时，它的作用就体现出来了。
为什么我们需要AssemblyDependencyResolver，它解决了什么痛点？
说实话，在
AssemblyDependencyResolver出现之前，尤其是在.NET Framework时代，处理程序集依赖真的是个让人头疼的问题。那时候，
AppDomain虽然提供了一定程度的隔离，但它的复杂性和限制（比如不能卸载单个
AppDomain）让很多高级场景变得非常棘手。最常见的痛点就是“DLL Hell”——不同的应用程序或组件需要同一DLL的不同版本，但系统只能加载其中一个，导致各种运行时错误。
在.NET Core的设计哲学里，一切都围绕着包（NuGet包）和部署的灵活性。传统的GAC概念被抛弃了，这意味着每个应用程序都可能带着自己的一套依赖。如果没有一个清晰、统一的机制来管理这些依赖，我们很快就会回到“DLL Hell”的泥潭。
AssemblyDependencyResolver正是为了解决这些痛点而生的。它带来的最大好处就是可预测性和隔离性。
首先，可预测性：通过强制所有依赖信息都写入
.deps.json，它让运行时在加载程序集时有了一个明确的查找依据。这就像给每个应用程序都配发了一张专属的“寻宝图”，避免了盲目搜索或依赖全局状态。无论是开发、测试还是部署，你都能知道你的应用会加载哪个版本的依赖，这极大简化了故障排查。
其次，隔离性：这一点在构建插件化应用时尤为关键。借助
AssemblyLoadContext，每个插件可以拥有自己的
AssemblyDependencyResolver，从而加载自己独有的依赖集，即使这些依赖与主应用程序或其他插件的依赖版本冲突，它们也能在各自的隔离空间中和谐共存。这彻底解决了不同组件间DLL版本冲突的问题，让构建健壮、可扩展的插件系统成为可能。它让我们可以大胆地让插件自带依赖，而不用担心会“污染”主应用程序的环境。
AssemblyDependencyResolver的工作原理：深入.deps.json和探测路径
要真正理解
AssemblyDependencyResolver，我们就得扒开它的核心——
.deps.json文件，并看看它是如何利用这个文件来构建探测路径的。
.deps.json文件是.NET SDK在构建项目时自动生成的一个JSON文件，它位于应用程序的输出目录中。这个文件包含了项目的所有直接和间接依赖项的元数据，包括：
targets: 这是最核心的部分，它定义了针对特定目标框架（如
.NETCoreApp,Version=vX.Y）的依赖项列表。每个条目都指向一个库，并列出该库在运行时所需的程序集文件（DLLs）及其相对路径。
libraries: 提供了每个依赖库的详细信息，如类型（project, package）、版本、哈希值等。
runtimeTarget: 指定了应用程序运行时的目标框架。
当
AssemblyDependencyResolver被初始化时（通常是通过
AssemblyLoadContext），它会解析这个
.deps.json文件，构建一个内部的依赖图和文件映射表。例如，如果你的应用依赖了
Newtonsoft.Json，
.deps.json中会有一个条目，大概会指示
Newtonsoft.Json.dll位于
newtonsoft.json/13.0.1/lib/net6.0/Newtonsoft.Json.dll这样的相对路径下。
有了这份“地图”，
AssemblyDependencyResolver就能开始构建它的“探测路径”列表了。这些路径是它在运行时查找DLL的顺序：
-
应用程序基目录: 这是最优先的，通常是应用程序的可执行文件所在的目录。任何直接放在这里的DLL都会被首先考虑。
通过
.deps.json解析出的相对路径: 这是
AssemblyDependencyResolver的独特之处。它不会像旧的加载器那样去搜索一堆预设的目录，而是直接根据
.deps.json中记录的相对路径来构建实际的查找路径。比如，如果
.deps.json说
Newtonsoft.Json.dll在
./Newtonsoft.Json/13.0.1/lib/net6.0/，它就会直接尝试去这个路径下加载。 共享框架目录: 如果应用程序是框架依赖型部署，
AssemblyDependencyResolver还会根据
.runtimeconfig.json中指定的框架版本，去查找对应的共享框架（如
Microsoft.NETCore.App）的安装目录。这确保了应用程序可以利用系统上已安装的共享运行时。
当
AssemblyLoadContext需要加载一个程序集时，它会委托
AssemblyDependencyResolver去执行
ResolveAssemblyToPath或
ResolveUnmanagedDllToPath方法。
AssemblyDependencyResolver会根据上述的探测路径和
.deps.json的信息，尝试找到匹配的DLL文件。一旦找到，它就会返回该文件的完整路径，然后
AssemblyLoadContext就可以从这个路径加载程序集了。这个过程是高度优化的，因为它避免了不必要的磁盘I/O和文件枚举，直接指向了可能的位置。
如何自定义AssemblyDependencyResolver的行为或处理特殊场景？
虽然
AssemblyDependencyResolver本身是一个相对固定的解析器，但我们仍然可以通过结合
AssemblyLoadContext来间接“自定义”它的行为，或者说，利用它来处理一些复杂的特殊场景，尤其是插件化架构。
最常见的定制场景就是构建一个隔离的插件加载机制。设想你有一个主应用程序，它需要动态加载多个第三方插件，而这些插件可能各自依赖不同版本的同一个库。这时，你不能让所有插件都共享默认的
AssemblyLoadContext和它的
AssemblyDependencyResolver，因为那会导致版本冲突。
解决方案是为每个插件创建一个独立的AssemblyLoadContext
实例，并为每个
AssemblyLoadContext配置它自己的
AssemblyDependencyResolver。这个
AssemblyDependencyResolver会指向插件目录下的
.deps.json文件，这样它就只会解析该插件的特定依赖。
下面是一个简化的代码示例，展示了如何为一个插件创建独立的加载上下文：
using System.Reflection;
using System.Runtime.Loader; // 注意这个命名空间
using System.IO;
public class PluginLoadContext : AssemblyLoadContext
{
private AssemblyDependencyResolver _resolver;
public PluginLoadContext(string pluginPath) : base(isCollectible: true) // isCollectible: true 允许卸载
{
// 假设插件的.deps.json和.runtimeconfig.json在pluginPath下
// 并且它们的名称与插件主程序集的文件名一致
var depsJsonPath = Path.Combine(pluginPath, $"{Path.GetFileName(pluginPath)}.deps.json");
// 检查文件是否存在，防止运行时错误
if (!File.Exists(depsJsonPath))
{
throw new FileNotFoundException($"Plugin .deps.json not found at: {depsJsonPath}");
}
// 为当前插件的上下文创建一个专属的AssemblyDependencyResolver
_resolver = new AssemblyDependencyResolver(depsJsonPath);
// 订阅Resolving事件，用于处理无法通过_resolver找到的程序集
// 这通常用于加载共享框架程序集，或处理主应用与插件共享的公共库
this.Resolving += OnResolving;
this.ResolvingUnmanagedDll += OnResolvingUnmanagedDll;
}
// 当LoadContext无法找到程序集时触发
protected override Assembly Load(AssemblyName assemblyName)
{
// 尝试通过插件自身的AssemblyDependencyResolver解析
string assemblyPath = _resolver.ResolveAssemblyToPath(assemblyName);
if (assemblyPath != null)
{
Console.WriteLine($"[PluginLoadContext] Loading '{assemblyName.Name}' from '{assemblyPath}' (plugin specific).");
return LoadFromAssemblyPath(assemblyPath);
}
// 如果插件的resolver找不到，则尝试从默认加载上下文加载
// 这对于共享的框架程序集（如System.*）或主应用程序提供的公共库非常重要
// 否则，每个插件都会尝试加载自己的System.Private.CoreLib，导致问题
var defaultAssembly = AssemblyLoadContext.Default.LoadFromAssemblyName(assemblyName);
if (defaultAssembly != null)
{
Console.WriteLine($"[PluginLoadContext] Loading '{assemblyName.Name}' from DefaultLoadContext (shared).");
return defaultAssembly;
}
Console.WriteLine($"[PluginLoadContext] Could not resolve assembly '{assemblyName.Name}'.");
return null; // 无法解析
}
// 处理非托管DLL的加载
protected override IntPtr LoadUnmanagedDll(string unmanagedDllName)
{
string libPath = _resolver.ResolveUnmanagedDllToPath(unmanagedDllName);
if (libPath != null)
{
Console.WriteLine($"[PluginLoadContext] Loading unmanaged DLL '{unmanagedDllName}' from '{libPath}' (plugin specific).");
return LoadUnmanagedDllFromPath(libPath);
}
// 尝试从默认加载上下文加载非托管DLL
var defaultLib = AssemblyLoadContext.Default.LoadUnmanagedDllFromAssemblyName(unmanagedDllName);
if (defaultLib != IntPtr.Zero)
{
Console.WriteLine($"[PluginLoadContext] Loading unmanaged DLL '{unmanagedDllName}' from DefaultLoadContext (shared).");
return defaultLib;
}
Console.WriteLine($"[PluginLoadContext] Could not resolve unmanaged DLL '{unmanagedDllName}'.");
return IntPtr.Zero;
}
// 额外的事件处理方法，通常在Load方法中已经处理了，但可以作为后备
private Assembly OnResolving(AssemblyLoadContext context, AssemblyName name)
{
// 这个方法会被Load方法调用，这里可以做一些额外的日志或诊断
return null;
}
private IntPtr OnResolvingUnmanagedDll(Assembly assembly, string unmanagedDllName)
{
// 这个方法会被LoadUnmanagedDll调用，这里可以做一些额外的日志或诊断
return IntPtr.Zero;
}
}
// 示例用法：
// string pluginDirectory = "/path/to/your/plugin"; // 假设这是插件的根目录
// try
// {
// var pluginContext = new PluginLoadContext(pluginDirectory);
// // 假设插件的主程序集名为 MyPlugin.dll
// var pluginAssembly = pluginContext.LoadFromAssemblyName(new AssemblyName("MyPlugin"));
//
// // 动态调用插件中的方法
// var pluginType = pluginAssembly.GetType("MyPlugin.PluginEntry");
// if (pluginType != null)
// {
// var instance = Activator.CreateInstance(pluginType);
// var method = pluginType.GetMethod("Run");
// method?.Invoke(instance, null);
// }
//
// // 如果需要卸载插件（仅当isCollectible为true时有效）
// // pluginContext.Unload();
// }
// catch (Exception ex)
// {
// Console.WriteLine($"Error loading plugin: {ex.Message}");
// }在这个例子中，每个
PluginLoadContext都有自己的
AssemblyDependencyResolver，它只关心自己的
.deps.json。当插件内部的代码需要加载一个DLL时，
PluginLoadContext会首先询问自己的
_resolver。如果
_resolver找不到（通常是因为这个DLL是共享框架的一部分，或者是一个由主应用程序提供的公共库），它就会回退到
AssemblyLoadContext.Default去加载。这种“先私后公”的加载策略是实现插件隔离的关键。
除了插件场景，
AssemblyDependencyResolver也能帮助我们处理一些边缘情况，比如： 部署优化: 通过分析
.deps.json，可以更精确地知道哪些文件是运行时真正需要的，从而优化部署包的大小。 诊断问题: 如果遇到DLL加载失败，
.deps.json和
AssemblyDependencyResolver的日志输出（如果开启了）能提供宝贵的线索，告诉你它尝试去哪里找了，以及为什么没找到。
总而言之，
AssemblyDependencyResolver本身并不直接提供很多“自定义”的API，但它作为一个构建块，与
AssemblyLoadContext结合使用时，能解锁非常强大的自定义加载行为，是构建现代.NET应用，尤其是微服务和插件化架构不可或缺的一部分。
