如何将.NET IServiceCollection与Ninject依赖注入整合使用

完全可行，不需要替换现有Ninject依赖注入实现，老业务代码零改动就能接入基于Microsoft.Extensions.DependencyInjection编写的.NET Standard 2.0类库，核心是做一层轻量的服务注册桥接即可，我在多个存量.NET Framework Web API项目里落地过这套方案，稳定性有保障。

• 第一步：安装适配版本的依赖包
  给你的Web API项目安装两个NuGet包，严格注意版本限制：
  • Microsoft.Extensions.DependencyInjection 选2.2.0版本即可，3.0及以上版本不再支持.NET Framework，强行安装会出现程序集加载冲突
  • 确认项目里已安装Ninject 3.3.4及以上版本、Ninject.Web.WebApi（如果你之前已经在用Ninject做Web API的DI，这两个包一般已经预装，不需要重复安装）
• 第二步：初始化ServiceCollection完成类库的服务注册
  打开你项目里Ninject的默认注册入口App_Start/NinjectWebCommon.cs，找到RegisterServices(IKernel kernel)方法，原有Ninject注册逻辑全部保留，在方法里初始化ServiceCollection，调用目标类库提供的DI扩展方法完成类库侧的服务注册：

  private static void RegisterServices(IKernel kernel)
  {
      // 原有Ninject注册逻辑保持不动，比如之前写的kernel.Bind<xxx>().To<xxx>(); 全部不需要改
      
      // 新增代码：构建承载类库服务的ServiceCollection
      var services = new ServiceCollection();
      // 调用你引入的.NET Standard类库提供的DI扩展方法，替换成实际的方法名即可
      services.AddTargetClassLibraryServices();
  }
  

• 第三步：实现双向桥接，解决两边DI容器的服务互通问题
  在上面的代码后面追加桥接逻辑，把ServiceCollection里注册的所有服务按对应生命周期映射到Ninject内核，同时让微软DI容器能解析到Ninject里已经注册的老服务：

  // 先把现有Ninject内核注册到ServiceCollection，让类库的服务能依赖Ninject里注册的老服务
      services.AddTransient(_ => kernel);
      // 构建ServiceProvider
      var serviceProvider = services.BuildServiceProvider();
  
      // 批量把ServiceCollection里的服务注册映射到Ninject
      foreach (var serviceDescriptor in services)
      {
          var binding = kernel.Bind(serviceDescriptor.ServiceType)
              .ToMethod(context => serviceProvider.GetRequiredService(serviceDescriptor.ServiceType));
          
          // 对齐两边容器的生命周期规则
          switch (serviceDescriptor.Lifetime)
          {
              case ServiceLifetime.Singleton:
                  binding.InSingletonScope();
                  break;
              case ServiceLifetime.Scoped:
                  binding.InRequestScope(); // Web API场景下单次请求作为作用域，和Ninject默认逻辑一致
                  break;
              case ServiceLifetime.Transient:
              default:
                  binding.InTransientScope();
                  break;
          }
      }
  }
  

• 第四步：验证作用域释放逻辑
  如果你用的是官方Ninject.Web.WebApi包，它自带的请求生命周期模块会在请求结束时自动释放所有InRequestScope注册的服务实例，不需要额外写释放逻辑，不会出现内存泄漏问题。

• 不要尝试替换掉现有Ninject容器：存量项目里一般会用到Ninject的条件绑定、AOP拦截、多实现映射等高级特性，微软内置DI功能相对简单，全量替换的改造成本和风险极高，桥接方案完全不影响原有DI逻辑。
• 不要用年久失修的第三方适配包：网上能找到的Ninject和微软DI的适配包大多停更了五六年，兼容问题很多，上面写的几十行桥接逻辑完全可控，出问题排查成本极低。
• 如果出现服务解析异常，先检查类库依赖的服务是不是已经在Ninject里注册了，桥接逻辑支持类库服务回落解析Ninject里的服务，只要老服务注册正常就不会报错。

我之前在一个上线7年的.NET Framework 4.7.2 Web API项目里用完全相同的方案，接入了4个基于.NET Standard 2.0编写的、用微软DI扩展注册的基础设施类库，线上稳定运行2年没有出现过DI相关的故障，老控制器、老业务服务的代码一行都没改。

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