dependency-injection

O código resolveu um serviço de um escopo de DI ou do provider raiz depois que ele foi descartado. Capture IServiceScopeFactory em vez de IServiceProvider e crie um novo escopo onde o trabalho é executado.

AddDbContextPool entrega um DbContext com escopo por escopo de DI, então não consegue executar duas consultas ao mesmo tempo. AddDbContextFactory e AddPooledDbContextFactory entregam um contexto por chamada, que é o que consultas em paralelo exigem. Medido no EF Core 11 RC 1: a factory com pool cria um contexto em 342 ns e 40 B contra 17 us e 44 KB.

Antes do Aspire 13.5.4, cada health check do AppHost em um recurso AddKafka criava um novo producer do Confluent que ninguém descartava, então as threads de polling se acumulavam e o AppHost queimava CPU. A correção, e a armadilha do HealthCheckRegistration.Factory por trás dela, vale também para os seus próprios health checks.

Um singleton não pode injetar um DbContext, mas pode injetar IDbContextFactory<T>, porque AddDbContextFactory registra a fábrica como singleton por padrão. Crie e descarte um contexto por chamada, nunca guarde a instância.

Implemente IValidateOptions<T>, registre na DI e encadeie ValidateOnStart para que um appsettings.json ruim derrube o processo em vez da primeira requisição que tocar nele. Cobre a sobrecarga Validate<TValidator>() do .NET 11, validação assíncrona com IAsyncValidateOptions<T> e os três lugares onde ValidateOnStart silenciosamente não faz nada.

Use IOptions<T> por padrão. Use IOptionsMonitor<T> quando um singleton precisa enxergar recargas de configuração, e IOptionsSnapshot<T> apenas quando um consumidor scoped precisa de um valor estável durante uma requisição. O eixo que decide é o tempo de vida do consumidor, não o formato das configurações.

O EF Core lança isso quando AddDbContext nunca rodou, rodou depois de Build ou o construtor do contexto recebe o DbContextOptions errado. Registre antes de Build e use DbContextOptions<SeuContexto>.

Registre várias implementações do mesmo tipo de serviço sob uma chave com AddKeyedSingleton/Scoped/Transient e depois resolva-as com [FromKeyedServices], GetRequiredKeyedService ou KeyedService.AnyKey. Os registros com chave e sem chave são tabelas separadas, e esse é o detalhe que pega quase todo mundo.

Um BackgroundService é um singleton, então não pode injetar diretamente um serviço scoped como um DbContext. Receba IServiceScopeFactory, abra um scope por unidade de trabalho com CreateAsyncScope, resolva dentro dele e descarte-o quando o trabalho terminar.

Uma lista de verificação passo a passo para remover o MediatR 12-14 e substituir os handlers de IRequest, ISender, os pipeline behaviors e INotification por classes de serviço simples e injeção por construtor.