Cuando trabajas con inyección de dependencias en ASP.NET Core, es frecuente encontrarse con una pregunta importante: cómo resolver un servicio con tiempo de vida scoped fuera del flujo normal de una petición HTTP. La respuesta práctica es usar IServiceScopeFactory.CreateScope para crear manualmente un alcance de DI y resolver servicios scoped de forma segura.
Los servicios en ASP.NET Core tienen tres tiempos de vida principales: Singleton creado una sola vez para toda la aplicación, Scoped creado una vez por cada petición HTTP y Transient creado cada vez que se solicita. En controladores y middleware no suele ser un problema porque el framework crea automáticamente un scope por cada petición. El reto aparece cuando estás fuera de una petición, por ejemplo en un servicio en segundo plano como BackgroundService o IHostedService, en un job programado o en una aplicación de consola usando el Generic Host.
No debes inyectar un servicio scoped directamente en un singleton. Si intentas inyectar ApplicationDbContext u otro servicio scoped dentro de un servicio singleton, el contenedor DI no podrá gestionar correctamente su ciclo de vida y provocará errores o fugas de recursos.
IServiceScopeFactory.CreateScope permite crear un alcance de DI manualmente. Dentro de ese scope puedes resolver servicios scoped y el contenedor se encarga de su eliminación al cerrar el alcance. En la práctica inyectas IServiceScopeFactory en tu BackgroundService, y en cada iteración creas un scope, llamas a scope.ServiceProvider.GetRequiredService para obtener el ApplicationDbContext u otros servicios, realizas el trabajo y dejas que el using o la disposición del scope libere los recursos.
Una forma conceptual de usarlo es: inyectar IServiceScopeFactory en el constructor del servicio en segundo plano, en el bucle de trabajo hacer using var scope = scopeFactory.CreateScope sujeto a la token de cancelación, resolver el servicio scoped desde scope.ServiceProvider indicando el tipo necesario, ejecutar la lógica y permitir que al salir del using el scope y los servicios resueltos se eliminen correctamente.
Buenas prácticas adicionales incluyen: crear un scope por unidad de trabajo (no por cada operación pequeña), evitar resolver muchos servicios en cascada sin necesidad y preferir patrones de mediador o colas para dividir trabajo pesado. En versiones más recientes tambin puedes considerar CreateAsyncScope para escenarios async con disposición asÃncrona.
En Q2BSTUDIO somos especialistas en desarrollar soluciones empresariales escalables y robustas. Si necesitas arquitecturas que integren servicios en segundo plano, accesso a bases de datos con contextos gestionados correctamente o aplicaciones distribuÃdas, podemos ayudarte con aplicaciones a medida y software a medida optimizadas para rendimiento y mantenibilidad. Además ofrecemos apoyo en migraciones y despliegues en la nube con soluciones seguras en inteligencia artificial e ia para empresas que mejoran procesos y automatizan decisiones.
Nuestros servicios abarcan inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios de inteligencia de negocio, agentes IA y Power BI. Si te interesa garantizar la correcta gestión del ciclo de vida de tus dependencias en aplicaciones .NET, al mismo tiempo que mejoras tu plataforma con soluciones de IA o despliegues seguros en la nube, en Q2BSTUDIO combinamos experiencia técnica y prácticas recomendadas para conseguirlo.
En resumen, cuando necesites resolver servicios scoped fuera del pipeline HTTP utiliza IServiceScopeFactory.CreateScope, resuelve servicios desde scope.ServiceProvider y permite que el alcance gestione la disposición. Esto evita problemas de ciclo de vida, asegura la liberación de recursos y es la forma recomendada de integrar DbContext y otros servicios scoped en servicios en segundo plano, jobs programados y aplicaciones hosteadas.
.jpg)
.jpg)