Windows Services y Worker Services son dos formas de crear procesos de larga duración en el ecosistema de Microsoft.
Windows Services pertenecen al .NET Framework y se ejecutan como servicios del sistema en Windows. Worker Services son la evolución moderna en .NET (Core/5+) y permiten procesos en segundo plano multiplataforma, usando el modelo de hospedaje de .NET.
¿Qué es un Windows Service? es una aplicación de larga duración que se ejecuta en su propia sesión, sin interfaz de usuario, iniciándose con el sistema operativo y administrándose desde el administrador de servicios de Windows. Históricamente se conocen como NT services y están pensados para tareas en segundo plano exclusivamente en Windows
¿Qué es .NET Worker Services? es una aplicación de fondo basada en el host genérico de .NET (IHostedService/BackgroundService). Permite procesar colas, tareas programadas o trabajos intensivos sin UI, y puede ejecutarse en Windows, Linux y macOS. Es la alternativa moderna a los servicios de Windows, con plantillas oficiales y soporte de extensiones de .NET para configuración, DI y logging.
Windows Services
- Modelo clásico, ligado a Windows.
- Pensado para .NET Framework.
- Difícil de portar, instalar y mantener en entornos modernos o cloud.
Worker Services
- Modelo moderno basado en el Generic Host de .NET.
- Funciona en Windows, Linux y macOS.
- Se integra nativamente con DI, logging, configuración, health checks, contenedores y DevOps.
- Puede ejecutarse como servicio de Windows, como systemd en Linux o dentro de Docker.
Similitudes:
- Larga duración: Ambos modelos ejecutan tareas persistentes en segundo plano sin interfaz gráfica.
- Automatización de procesos: Son adecuados para trabajos programados, procesamiento de colas y servicios que requieren estar activos continuamente.
Diferencias clave:
- Plataforma: Windows Services solo en Windows; Worker Services son multiplataforma.
- Modelo de hospedaje: Windows Services usan el modelo del SO y ServiceController; Worker Services usan el host genérico de .NET con IHostedService/BackgroundService.
- Desarrollo y despliegue: Windows Services requieren instalación y registro como servicio del sistema; Worker Services se hospedan como consola, servicio de Windows, systemd en Linux o contenedor.
- Ecosistema moderno: Worker Services integran DI, configuración y logging de .NET; Windows Services carecen de estas integraciones nativas en .NET Framework.
¿Cuándo usar cada uno?
- Elige Windows Services: Cuando estás atado a Windows Server y a la administración nativa de servicios del sistema, o mantienes una solución existente en .NET Framework.
- Elige Worker Services: Cuando buscas portabilidad, contenedores, despliegues cloud/devops, integración con DI y observabilidad moderna en .NET.
Comparativa entre Windows Services y Worker Services
He aquí una tabla comparativa:
| Aspecto | Windows Services (.NET Framework) | Worker Services (.NET moderno) |
|---|---|---|
| Plataforma | Solo Windows | Multiplataforma (Windows, Linux, macOS) |
| Modelo de ejecución | Servicio del sistema administrado por SCM (Service Control Manager) | Host genérico de .NET (IHostedService/BackgroundService) |
| Instalación | Registro como servicio (sc.exe, instaladores, herramientas de administración) | Ejecutable de consola, servicio de Windows, systemd, contenedor |
| Integraciones | Limitadas; sin DI/Logging nativo del host de .NET | DI, configuración, logging, health checks, extensiones de .NET |
| Casos típicos | Procesos en background en entornos Windows/legacy | Trabajos en background portables, cloud-native, contenedores |
| Plantillas oficiales | Enfoque clásico de .NET Framework | Plantilla “Worker Service” en .NET |
| Mantenimiento | Dependiente de Windows y SCM | Observabilidad moderna, despliegues flexibles |
Worker Services son la evolución moderna de Windows Services.
Creando un Worker Service
Para crear un Worker Service usaremos la herramienta dotnet. Ese servicio se ejecuatrá cada 5 segundos y mostrará un mensaje.
1. Crear el proyecto Worker:
$ dotnet new worker -n MiWorkerService
2. Nos ubicamos en el directorio creado:
$ cd MiWorkerService
3. Editamos la clase Worker.cs
using Microsoft.Extensions.Hosting; using Microsoft.Extensions.Logging; namespace MiWorkerService; public class Worker : BackgroundService { private readonly ILogger<Worker> _logger; public Worker(ILogger<Worker> logger) { _logger = logger; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { _logger.LogInformation("Worker ejecutándose a las: {time}", DateTimeOffset.Now); await Task.Delay(5000, stoppingToken); } } }
4. Editamos el programa principal Program.cs
using MiWorkerService; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Hosting; IHost host = Host.CreateDefaultBuilder(args) .ConfigureServices(services => { services.AddHostedService<Worker>(); }) .Build(); await host.RunAsync();
5. Ejecutar proyecto:
$ dotnet build $ dotnet run
Salida:
info: MiWorkerService.Worker[0] Worker ejecutándose a las: 12/03/2025 21:10:34 -06:00 info: MiWorkerService.Worker[0] Worker ejecutándose a las: 12/03/2025 21:10:39 -06:00 info: MiWorkerService.Worker[0] Worker ejecutándose a las: 12/03/2025 21:10:44 -06:00
Podríamos implementarlo como un Servicio, pero será en otra ocasión.
Conclusión: un Worker Service es como un Windows Service modernizado que funciona en cualquier plataforma y listo para ser implementado en la Nube y/o Docker.
Enlaces:
https://learn.microsoft.com/es-es/dotnet/core/extensions/workershttps://medium.com/@adebanjoemmanuel01/running-a-worker-service-as-a-windows-service-c1d12a28a73c
https://web.valuesite.cl/index.php/2024/11/25/la-utilizacion-de-worker-service-para-servicios-automaticos-vs-frameworks/
https://learn.microsoft.com/es-es/dotnet/core/extensions/windows-service


No hay comentarios:
Publicar un comentario