.NET 6 Web API DI同项目依赖服务解析失败问题

问题表现 #

• 业务组件PaymentComponent构造函数注入6个依赖项，所有依赖均已通过静态扩展方法完成Scoped生命周期注册
• 依赖类放在PaymentComponent项目内部时，DI容器抛出服务解析异常，提示对应接口未注册；将依赖类迁移到独立的PaymentHelper项目后，不修改任何业务代码DI即可正常运行
• 该问题在解决方案所有同类项目中普遍存在，项目基于.NET 6 Web API构建
• 项目结构参考：
  

核心异常信息：

InvalidOperationException: Unable to resolve service for type 'ASP.Components.Policy.Payment.PolisaPremijaNacinSredstvaPlacanja.IPolisaPremijaNacinSredstvaPlacanjaUseCase' while attempting to activate 'ASP.Components.Policy.Payment.PaymentComponent'.

最小复现规则：

• 手动调用AddScoped直接注册组件，运行正常
• 通过自定义ScanForComponents方法扫描程序集批量注册组件，仅当依赖类存放在独立项目时运行正常
• 最小复现项目结构：
  

问题根因 #

问题出在程序集加载逻辑：
当前扫描代码使用Assembly.LoadFile()加载目标dll，该方法会将程序集加载到独立的加载上下文，和.NET默认加载上下文的类型不共享。

1. 手动调用依赖注册方法时，代码中引用的接口、实现类型均来自默认加载上下文的程序集，注册到DI容器的服务类型是默认上下文的类型
2. 用Assembly.LoadFile()加载同路径下的组件dll时，扫描得到的组件类型来自独立加载上下文，其构造函数中引用的依赖接口类型，是独立加载上下文中的同名类型，和默认上下文注册的类型不是同一个对象（即使命名空间、类型名完全一致），DI容器判定该依赖未注册，抛出异常
3. 依赖类迁移到独立项目后之所以"正常"，是因为启动项目直接引用了独立依赖项目，程序集被提前加载到默认上下文，LoadFile加载的组件程序集解析依赖时会优先指向默认上下文的类型，刚好匹配已注册的服务，属于巧合，没有解决根本问题。

修复方法 #

替换程序集加载方式，确保所有加载的程序集都使用默认加载上下文，避免类型不匹配。修改AssemblyHelper代码如下：

using System.Reflection;

namespace PolicyAPI.Helpers
{
    public class AssemblyHelper
    {
        public static List<Assembly> GetAssemblies(string startWith)
        {
            var returnAssemblies = new List<Assembly>();
            var binPath = Path.GetDirectoryName(Assembly.GetEntryAssembly()!.Location)!;
            var dllPaths = Directory.GetFiles(binPath, $"{startWith}*.dll");
            foreach (var dllPath in dllPaths)
            {
                // 替换LoadFile，通过程序集全名加载，统一使用默认加载上下文
                var assemblyName = AssemblyName.GetAssemblyName(dllPath);
                returnAssemblies.Add(Assembly.Load(assemblyName));
            }
            return returnAssemblies;
        }
    }
}

额外优化建议：可以在扫描组件程序集时，同时扫描程序集中定义的依赖注册扩展方法（例如约定名为AddDependencies的静态方法），自动完成依赖注册，避免手动调用注册方法遗漏的问题。

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