Tag: dependency-injection

EF Core throws this when AddDbContext never ran, ran after Build, or your context's constructor takes the wrong DbContextOptions. Register before Build and use DbContextOptions<YourContext>.

Register more than one implementation of the same interface under a key with AddKeyedSingleton/Scoped/Transient, then resolve them with [FromKeyedServices], GetRequiredKeyedService, or KeyedService.AnyKey. The keyed and non-keyed registries are separate, which is the gotcha that bites most people.

A BackgroundService is a singleton, so it cannot inject a scoped service like a DbContext directly. Take IServiceScopeFactory, open one scope per unit of work with CreateAsyncScope, resolve inside it, and dispose it when the work is done.

A step-by-step checklist to remove MediatR 12-14 and replace IRequest handlers, ISender, pipeline behaviors, and INotification with plain service classes and constructor injection.

For new code, plain service classes are the better default. MediatR's July 2025 license change matters only if you sit above the $5M Community threshold or refuse the RPL-1.5 copyleft. Keep MediatR when pipeline behaviors are load-bearing.

ASP.NET Core's scope validation throws this when a singleton would capture a scoped dependency for the rest of the process. Make the consumer scoped, or take IServiceScopeFactory and create a scope on demand.

ASP.NET Core throws this when a constructor asks for a type that was never registered, was registered on the wrong container, or was added after the host was built. Three concrete fixes cover almost every case.

EF Core 11 Preview 3 introduces RemoveDbContext, RemoveExtension, and a parameterless AddPooledDbContextFactory overload, removing the boilerplate around swapping providers in tests and centralizing pooled factory configuration.