.NET的AssemblyDependencyResolver如何解析依赖项？-C#.Net教程-PHP中文网

AssemblyDependencyResolver通过解析.deps.json和.runtimeconfig.json文件，为.NET Core应用提供可预测的程序集加载机制。它依据.deps.json中的依赖映射和探测路径，精准定位DLL，避免版本冲突，解决“DLL Hell”问题。结合AssemblyLoadContext，可实现插件隔离，支持自定义加载策略，确保各组件依赖独立，提升应用可维护性与扩展性。

.net的assemblydependencyresolver如何解析依赖项？

.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
```
登录后复制
的日志输出（如果开启了）能提供宝贵的线索，告诉你它尝试去哪里找了，以及为什么没找到。

总而言之，