ASP.NET Core集成Identity初始化默认账号角色时触发服务解析异常

• 违反ASP.NET Core框架的ConfigureServices调用约定：框架仅会给该方法传入IServiceCollection类型参数，你手动新增的IServiceProvider参数不会被框架自动赋值。更关键的是，这个方法的执行阶段整个服务容器还未完成最终构建，此时提前尝试解析已注册的服务，必然会触发依赖解析异常。
• 报错中提到的ApplicationPartManager是MVC、Razor运行时编译链路的核心服务，该服务是在服务注册流程中逐步添加完成的，你在注册流程尚未走完时就尝试解析这类服务，自然会抛出“无法解析依赖”的异常。
• 提前在服务注册阶段调用需要解析UserManager、RoleManager的初始化逻辑，除了当前出现的Razor服务报错，后续还会因为Scoped服务生命周期不匹配，引出更多解析异常。

1. 修正ConfigureServices方法定义 #

删除方法上多余的IServiceProvider参数，移除方法内直接调用初始化逻辑的代码，恢复为符合框架规范的方法签名：

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<AppDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));
    services.AddDatabaseDeveloperPageExceptionFilter();

    services.AddIdentity<AppUser, IdentityRole>(options => options.SignIn.RequireConfirmedAccount = true)
            .AddClaimsPrincipalFactory<UserClaimsPrincipalFactory<AppUser, IdentityRole>>()
            .AddEntityFrameworkStores<AppDbContext>().AddDefaultTokenProviders().AddDefaultUI();

    services.AddControllersWithViews();
    services.AddRazorPages();
}

2. 将初始化逻辑调整到容器构建完成后执行 #

推荐在服务容器完全构建、所有服务注册完成后再执行初始化，具体位置根据你的项目托管模式选择：

• 采用传统Startup类的项目：在Configure方法中，利用应用构建好的根服务容器创建作用域，执行初始化逻辑：

  public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
  {
      // 保留原有的全部中间件配置逻辑，比如开发环境异常页、HTTPS重定向、静态文件服务等
      // ...
  
      // 创建服务作用域执行初始化（UserManager、RoleManager、AppDbContext均为Scoped生命周期，必须通过作用域解析）
      using (var scope = app.ApplicationServices.CreateScope())
      {
          var scopeServiceProvider = scope.ServiceProvider;
          // 同步等待初始化逻辑执行完成，避免Configure方法异步带来的执行时机问题
          CreateDefaultRoles(scopeServiceProvider).GetAwaiter().GetResult();
      }
  
      // 保留原有的路由、身份认证、授权、应用终结点配置逻辑
  }
  

• 采用.NET 6+最小托管模型（顶级语句）的项目：直接在var app = builder.Build();、app.Run();之间插入上述创建作用域、调用初始化方法的代码即可，效果完全一致。

3. 原有初始化方法无需大幅调整 #

你编写的CreateDefaultRoles核心业务逻辑是通顺的，仅需补充基础的错误处理即可，比如创建角色、创建用户失败时记录错误详情，不要静默吞掉操作返回的结果，方便后续定位问题。

• 严禁在ConfigureServices阶段手动从IServiceCollection构建临时的IServiceProvider解析服务，这种操作会导致Singleton服务被重复构建，丢失原有单例状态，直接触发和当前报错一致的ApplicationPartManager解析失败问题。
• 涉及数据库访问的初始化逻辑，必须放在独立的服务作用域中执行，禁止直接从根服务容器解析Scoped生命周期的服务（比如EF Core的DbContext），造成服务无法释放、内存泄漏。

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