如何确保AssemblyLoadContext从头加载所有程序集并替换依赖程序集？

你的问题核心在于自定义AssemblyLoadContext(ALC)没有正确处理依赖程序集的解析逻辑，而且当前实现里的Assembly.LoadFile也无法自动处理依赖链，同时你只显式加载了aA.dll，它的依赖bB.dll的加载请求没有被正确引导到自定义路径，最终回退到全局上下文加载了预存在的aB.dll。

下面是修复后的完整实现，我会一步步解释关键改动：

1. 改进自定义CollectibleAssemblyLoadContext #

首先我们要让ALC明确知道去哪里找替换的依赖程序集，并且正确处理依赖解析流程：

using System.Reflection;
using System.Runtime.Loader;

public class CollectibleAssemblyLoadContext : AssemblyLoadContext
{
    private readonly string _dependencyDirectory;
    // 记录需要替换的程序集名称（如原aB.dll的名称）与目标路径的映射
    private readonly Dictionary<string, string> _assemblyPathMappings;

    public CollectibleAssemblyLoadContext(string dependencyDirectory, Dictionary<string, string> assemblyPathMappings) 
        : base(isCollectible: true)
    {
        _dependencyDirectory = dependencyDirectory;
        _assemblyPathMappings = assemblyPathMappings;
    }

    protected override Assembly? Load(AssemblyName assemblyName)
    {
        // 优先拦截需要替换的程序集请求
        if (_assemblyPathMappings.TryGetValue(assemblyName.Name, out string? targetPath))
        {
            // 使用LoadFromAssemblyPath而非LoadFile：它会自动处理依赖解析，并将程序集纳入ALC缓存
            return LoadFromAssemblyPath(targetPath);
        }

        // 针对其他依赖，尝试从指定目录加载
        string assemblyPath = Path.Combine(_dependencyDirectory, $"{assemblyName.Name}.dll");
        if (File.Exists(assemblyPath))
        {
            return LoadFromAssemblyPath(assemblyPath);
        }

        // 最后回退到全局上下文加载（可根据需求调整是否保留此逻辑）
        return null;
    }

    protected override IntPtr LoadUnmanagedDll(string unmanagedDllName)
    {
        // 若存在非托管依赖，可在此处添加类似的路径处理逻辑
        string dllPath = Path.Combine(_dependencyDirectory, unmanagedDllName);
        if (File.Exists(dllPath))
        {
            return LoadUnmanagedDllFromPath(dllPath);
        }
        return base.LoadUnmanagedDll(unmanagedDllName);
    }
}

2. 修改实例创建方法 #

接下来调整GetRaw方法，确保aA.dll和它的依赖bB.dll都被纳入自定义ALC的管理范围：

public static object GetRaw<T>() where T : class
{
    // 假设自定义替换的bB.dll放在当前程序目录下的CustomAssemblies文件夹中
    string customAssemblyDir = Path.Combine(AppContext.BaseDirectory, "CustomAssemblies");
    // 映射原程序集名称到目标替换文件的完整路径
    var assemblyMappings = new Dictionary<string, string>
    {
        ["aB"] = Path.Combine(customAssemblyDir, "bB.dll")
    };

    // 使用using管理可回收ALC的生命周期，确保资源及时释放
    using var context = new CollectibleAssemblyLoadContext(customAssemblyDir, assemblyMappings);
    
    // 将aA.dll加载到自定义ALC中
    Assembly aAAssembly = context.LoadFromAssemblyPath(typeof(T).Assembly.Location);
    
    Type programType = aAAssembly.GetType(typeof(T).FullName)!;
    object result = Activator.CreateInstance(programType)!;

    return result;
}

关键改动说明 #

• 替换Assembly.LoadFile为LoadFromAssemblyPath：LoadFile仅加载单个程序集，不处理依赖也不加入ALC缓存；LoadFromAssemblyPath会触发ALC的依赖解析逻辑，将加载的程序集纳入ALC管理，后续该程序集的所有依赖请求都会通过当前ALC的Load方法处理。
• 添加依赖目录与程序集映射：明确告诉ALC，当请求加载名为aB的程序集时，直接加载我们指定的bB.dll，避免回退到全局上下文。
• 覆盖完整依赖链：当aA.dll中的类型A创建B的实例时，CLR会向当前ALC请求加载B的程序集，这时Load方法会拦截请求并加载自定义的bB.dll，而非全局上下文的版本。
• 管理ALC生命周期：用using包裹可回收ALC，确保在实例不再被引用时能及时释放资源（前提是该ALC加载的所有对象没有被全局上下文持有引用）。

额外注意事项 #

• 确保bB.dll的AssemblyName（名称、版本）与原aB.dll完全一致，否则CLR会判定为不同程序集，导致类型不兼容。
• 如果程序存在多层依赖（比如B还依赖C.dll），只需将C.dll放入customAssemblyDir目录，ALC会自动从该目录加载，无需额外映射（除非你也需要替换C.dll）。
• 避免全局上下文提前加载aB.dll：如果在创建自定义ALC前，全局上下文已经加载了aB.dll，可能会因类型标识冲突导致问题，测试时需确保全局上下文未预加载该程序集。

内容的提问来源于stack exchange，提问作者DuckQueen