AssemblyDependencyResolver通过解析.deps.json和.runtimeconfig.json文件，为.NET Core应用提供可预测的程序集加载机制。它依据.deps.json中的依赖映射和探测路径，精准定位DLL，避免版本冲突，解决“DLL Hell”问题。结合AssemblyLoadContext，可实现插件隔离，支持自定义加载策略，确保各组件依赖独立，提升应用可维护性与扩展性。
.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应用，尤其是微服务和插件化架构不可或缺的一部分。
以上就是.NET的AssemblyDependencyResolver如何解析依赖项？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439255.html
微信扫一扫 
支付宝扫一扫 
