Etiqueta: dependency-injection

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.

Para código nuevo, las clases de servicio simples son la mejor opción por defecto. El cambio de licencia de MediatR de julio de 2025 importa solo si superas el umbral Community de 5 millones de dólares o rechazas el copyleft de la RPL-1.5. Conserva MediatR cuando los pipeline behaviors sean esenciales.

La validación de ámbitos de ASP.NET Core lanza esto cuando un singleton capturaría una dependencia scoped durante todo el proceso. Haz que el consumidor sea scoped, o toma IServiceScopeFactory y crea un ámbito bajo demanda.