Tag: dependency-injection

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.

Para código novo, classes de serviço simples são a melhor opção padrão. A mudança de licença do MediatR de julho de 2025 só importa se você estiver acima do limite Community de 5 milhões de dólares ou recusar o copyleft da RPL-1.5. Mantenha o MediatR quando os pipeline behaviors forem essenciais.

A validação de escopo do ASP.NET Core lança esta exceção quando um singleton capturaria uma dependência scoped pelo resto do processo. Torne o consumidor scoped, ou injete IServiceScopeFactory e crie um escopo sob demanda.

O ASP.NET Core lança esta exceção quando um construtor pede um tipo que nunca foi registrado, foi registrado no contêiner errado ou foi adicionado depois que o host foi construído. Três correções concretas cobrem quase todos os casos.

EF Core 11 Preview 3 introduz RemoveDbContext, RemoveExtension, e um overload sem parâmetros do AddPooledDbContextFactory, removendo o boilerplate de trocar providers em testes e centralizando a configuração da pooled factory.