A Windows service runs a long-lived .NET worker in the background without handling HTTP requests or presenting a user interface. Windows monitors and starts the installed application automatically, making it suitable for queue processing, scheduled work, and other headless tasks. section 34.2.2 section 34.2
The application itself is usually a worker service built on the generic IHost. It retains configuration, logging, dependency injection, and hosted-service support while avoiding the additional HTTP surface of ASP.NET Core. section 34.2 section 34.4
A practical Windows-service setup follows these steps:
- Create a worker-service application and register its IHostedService implementation with the generic host. section 34.2.1
- Add Microsoft.Extensions.Hosting.WindowsServices and call UseWindowsService() on IHostBuilder. section 34.2.2
- Publish or build the executable, then install it with the Windows sc utility and provide its executable path. section 34.2.2
- Manage startup, stopping, service identity, and error handling from the Windows Services control panel. section 34.2.2
Enabling Windows Service support
IHost host = Host.CreateDefaultBuilder(args) .ConfigureServices((context, services) => { services.AddHostedService<Worker>(); }) .UseWindowsService() .Build(); host.Run(); During development, UseWindowsService() has no effect when the application runs as a console app, so the same worker remains convenient to test locally. section 34.2.2
Listing 34.9 Adding Windows Service support to a worker service
IHost host = Host.CreateDefaultBuilder(args) #1 .ConfigureServices((hostContext, services) => #1 { #1 Services.AddHostedService<Worker>(); #1 }) #1 .UseWindowsService() #2 .Build(); host.Run(); #1 Configures your worker service as you would normally #2 Adds support for running as a Windows Service.
Use this annotated listing to see where Windows Service integration fits into ordinary worker-host configuration. section 34.2.2
