What the point to have IHostApplicationLifetime when you have IHostedService

We can only suppose to know what the designers of the framework were really thinking. The first use that comes to mind is the StopApplication method. It makes for a convenient method for a IHostedService to indicate that the application should stop. Either because everything is done (start app, poll something, process result poll, terminate and wait for external timed restart), or due to a catastrophic error.

I can see that the three properties called out by the OP could be of some use in extremely complicated lifetime scenarios, such as cooperating IHostedServices. According to the documentation ApplicationStarted is triggered when the 'application host if fully started'. This 'event' could then be used by IHostedServices to know that other services were available and then the ApplicationStopping 'event' would indicate that other hosted services were going away. Note that each IHostedService receives its StopAsync call serially. The seriality means that one service could be continuing to run long after the service it depends on shutsdown. That same 'event', could be used in some cases as a hint to the IHostedService to start shutting down so that StopAsync call could complete sooner and not impact the host shutdown.

And yes, the for the simple case there is not need to inject IHostedApplicationLifetime into the IHostedService.

Like most things nowadays, it's described in the Microsoft Docs:

IHostedService

When a host starts, it calls IHostedService.StartAsync on each implementation of IHostedService registered in the service container's collection of hosted services. In a web app, one of the IHostedService implementations is a web service that starts an HTTP server implementation.

IHostApplicationLifetime

Inject the IHostApplicationLifetime (formerly IApplicationLifetime) service into any class to handle post-startup and graceful shutdown tasks. Three properties on the interface are cancellation tokens used to register app start and app stop event handler methods. The interface also includes a StopApplication method, which allows apps to request a graceful shutdown.

So a hosted service interface is a "template" for a (custom) background task/service, while the host application lifetime service is an existying running service in the DI container (i.e. a Framework-provided service) that you can use/inject in any service.

Some examples

You have an IHostedService which must take app-level actions based on the app's state. It has a StartAsync and StopAsync, but if you need more control, e.g. "stopping", you'd inject that interface and subscribe to the events of interest.

Or in some other class (not IHostedService), you can similarly take special action based on the current state of the app; maybe you don't open new connections while the app is stopping, or reject requests.

Also, the interface has a handy StopApplication(), which lets you perform a graceful shutdown, where you have a chance to stop, close, dispose, etc. Far cleaner than Environment.Exit(1).

Some differences

Keep in mind the difference between the IHostedService methods:

• StartAsync(CancellationToken) "Triggered when the application host is ready to start the service."
• StopAsync(CancellationToken) "Triggered when the application host is performing a graceful shutdown."

... and those on IHostApplicationLifetime:

• ApplicationStarted "Triggered when the application host has fully started."
• ApplicationStopped "Triggered when the application host has performed a graceful shutdown."
• ApplicationStopping "Triggered when the application host is performing a graceful shutdown. Shutdown will block until this event completes."

As you can see they don't tell you the same things, exactly. So IHostApplicationLifetime gives you more control.