dependency-injection

El código resolvió un servicio desde un scope de DI o un proveedor raíz después de que fue liberado. Captura IServiceScopeFactory en lugar de IServiceProvider y crea un scope nuevo donde se ejecuta el trabajo.

AddDbContextPool entrega un DbContext con ámbito por cada ámbito de DI, así que no puede ejecutar dos consultas a la vez. AddDbContextFactory y AddPooledDbContextFactory te dan un contexto por llamada, que es lo que necesitan las consultas en paralelo. Medido en EF Core 11 RC 1: la factoría con pool crea un contexto en 342 ns y 40 B frente a 17 us y 44 KB.

Antes de Aspire 13.5.4, cada health check del AppHost sobre un recurso AddKafka creaba un nuevo productor de Confluent que nadie liberaba, así que los hilos de sondeo se acumulaban y el AppHost consumía CPU. La corrección, y la trampa de HealthCheckRegistration.Factory que hay detrás, también aplica a tus propios health checks.

Un singleton no puede inyectar un DbContext, pero sí puede inyectar IDbContextFactory<T>, porque AddDbContextFactory registra la fábrica como singleton por omisión. Crea y libera un contexto por llamada, nunca guardes la instancia.

Implementa IValidateOptions<T>, regístralo en DI y encadena ValidateOnStart para que un appsettings.json incorrecto mate el proceso en lugar de la primera solicitud que lo toque. Cubre la sobrecarga Validate<TValidator>() de .NET 11, la validación asíncrona con IAsyncValidateOptions<T> y los tres lugares donde ValidateOnStart no hace nada en silencio.

Usa IOptions<T> por defecto. Usa IOptionsMonitor<T> cuando un singleton debe ver recargas de configuración, e IOptionsSnapshot<T> solo cuando un consumidor scoped necesita un valor estable durante una solicitud. El eje que decide es el tiempo de vida del consumidor, no la forma de la configuración.

EF Core lanza esto cuando AddDbContext nunca se ejecutó, se ejecutó después de Build o el constructor del contexto recibe el DbContextOptions equivocado. Registra antes de Build y usa DbContextOptions<TuContexto>.

Registra varias implementaciones del mismo tipo de servicio bajo una clave con AddKeyedSingleton/Scoped/Transient y luego resuélvelas con [FromKeyedServices], GetRequiredKeyedService o KeyedService.AnyKey. Los registros con clave y sin clave son tablas separadas, y ese es el detalle que confunde a casi todos.

Un BackgroundService es un singleton, así que no puede inyectar directamente un servicio scoped como un DbContext. Toma IServiceScopeFactory, abre un scope por unidad de trabajo con CreateAsyncScope, resuelve dentro de él y deséchalo al terminar.

Una lista de verificación paso a paso para eliminar MediatR 12-14 y reemplazar los handlers de IRequest, ISender, los pipeline behaviors y INotification por clases de servicio simples e inyección por constructor.