.NET中AssemblyDependencyResolver的作用是解析程序集的依赖项，具体方式如下：加载程序集 AssemblyDependencyReso

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文件，它位于应用程序的输出目录中。这个文件包含了项目的所有直接和间接依赖项的元数据，包括：

1. targets: 这是最核心的部分，它定义了针对特定目标框架（如.NETCoreApp,Version=vX.Y）的依赖项列表。每个条目都指向一个库，并列出该库在运行时所需的程序集文件（DLLs）及其相对路径。
2. libraries: 提供了每个依赖库的详细信息，如类型（project, package）、版本、哈希值等。
3. 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的顺序：

1. 应用程序基目录: 这是最优先的，通常是应用程序的可执行文件所在的目录。任何直接放在这里的DLL都会被首先考虑。
2. 通过.deps.json解析出的相对路径: 这是AssemblyDependencyResolver的独特之处。它不会像旧的加载器那样去搜索一堆预设的目录，而是直接根据.deps.json中记录的相对路径来构建实际的查找路径。比如，如果.deps.json说Newtonsoft.Json.dll在./Newtonsoft.Json/13.0.1/lib/net6.0/，它就会直接尝试去这个路径下加载。
3. 共享框架目录: 如果应用程序是框架依赖型部署，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应用，尤其是微服务和插件化架构不可或缺的一部分。