Scoped服务在WebApplication构建器中解析失败，Host构建器中正常求因与方案

原因分析 #

核心差异在于WebApplicationBuilder默认启用了ValidateScopes验证（开发环境下），而Host.CreateApplicationBuilder默认关闭该验证。

你的DatabaseContext（多租户场景必然依赖ITenantProvider）通过AddDbContextPool注册时，EF Core的上下文池由根服务容器管理。当ValidateScopes开启时，根容器不允许解析Scoped生命周期的服务，因此抛出Cannot resolve scoped service 'ITenantProvider' from root provider异常。

控制台应用因未开启验证，即使根容器解析Scoped服务也不会报错，但这属于不符合DI生命周期规范的潜在问题。

解决方法 #

根据多租户需求，推荐以下方案：

方案1：替换AddDbContextPool为AddDbContext

池化上下文（AddDbContextPool）要求依赖服务为Singleton或Transient，无法兼容Scoped租户提供者。改用AddDbContext（默认Scoped生命周期），让上下文与租户提供者同属一个Scope：

builder.Services.AddDbContext<DatabaseContext>(opt => 
    opt.UseNpgsql("foobar")
       .UseSnakeCaseNamingConvention()
);

方案2：关闭ValidateScopes验证（不推荐开发环境使用）

若必须保留池化上下文，可关闭验证，但会隐藏生命周期不匹配的潜在问题：

var builder = WebApplication.CreateBuilder(args);
// 关闭Scope验证
builder.Host.ConfigureServices(services =>
{
    services.AddOptions<HostOptions>().Configure(options =>
    {
        options.ValidateScopes = false;
    });
});

// 后续服务注册不变
builder.Services.AddScoped<ITenantProvider, TenantProvider>();
builder.Services.AddDbContextPool<DatabaseContext>(opt => 
    opt.UseNpgsql("foobar")
       .UseSnakeCaseNamingConvention()
);

方案3：调整租户提供者生命周期（仅适用于非请求级租户场景）

若租户信息并非请求级（如固定租户），可将ITenantProvider改为Singleton生命周期：

builder.Services.AddSingleton<ITenantProvider, TenantProvider>();

此方案不适用于“每个请求对应不同租户”的典型多租户场景。

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