The best thing to do might be to provide a new interface that gives control over each of the relevant pieces:

• Before hosted services start
• After hosted services start
• Before hosted services stop
• After hosted services stop

This interface would probably be a superset of IApplicationLifetime.

Would this be an interface I can provide an implementation (or multiple) through the DI container, maybe something like:

interface IApplicationLifetimeEventsHandler 
{
    Task OnApplicationStart();
    Task OnApplicationStopping();
    Task OnApplicationStopped();
    
    Task OnServicesStarting();
    Task OnServicesStarted();
    Task OnServicesStopping();
    Task OnServicesStopped();
}

If that is the case and we can provide implementations, that would be good. Although I would question having to implement a type where I want to intercept just a single lifetime event, and have to provide default implementations of the others:

class MyLifetimeEventsHandler : IApplicationLifetimeEventsHandler
{
    public Task OnApplicationStart() => Task.CompletedTask;
    public Task OnApplicationStopping() => Task.CompletedTask;
    public Task OnApplicationStopped() => Task.CompletedTask;
    
    public async Task OnServicesStarting()
    {
      // Do some work here
    }
    
    public Task OnServicesStarted() => Task.CompletedTask;
    public Task OnServicesStopping() => Task.CompletedTask;
    public Task OnServicesStopped() => Task.CompletedTask;
}

Would individual interfaces work better, as they are more focused:

interface IHostedServicesStartedEventHandler
{

}

That would obviously expand the number of resolves you'd have to do, too many moving parts? Default interface methods would work a charm here ;-)

Is WebHost being refactored to use Host for the 3.x timeframe? I think normalizing when IApplicationLifetime.NotifyStarted() is called - but then you're already looking into changes here, as part of dotnet/extensions#1544

Alternatively, could we perhaps extend event registration through to the builder?:

new HostBuilder()
  .WithEvents(
    onServicesStarted: async () => {
    
    }
  )
  .Build();

That is largely superficial, the real power could be allowing the builder to collect a set of Action (much like here), meaning by extending the builder with custom extension methods, you can mix in more functionality, but simplifying the API the consumer uses?

E.g. in my design:

new HostBuilder()
  .UseDiscoveredModules() // Registers lifetime actions
  .Build();

I am trying to find an event that notify that and aspnet core application is now ready to server http requests.

I tried to use the IApplicationLifetime.ApplicationStarted but the event is raised before the application is ready to handle requests.

At the moment is there any way to perform that (hack or not)?

@linvi ApplicationStarted is raised after the server can accept HTTP requests.
https://github.com/aspnet/Hosting/blob/c37c50964d1451c22d085803ec54ec697c7fb81a/src/Microsoft.AspNetCore.Hosting/Internal/WebHost.cs#L147-L153

Are you also dependent on the hosted services for request processing?

Yes I am.

I've been thinking about this a bit and I think the model I'd prefer is more optional interfaces that an IHostedService may implement to get notified about more events. These wouldn't be recognized through the DI container, the host would opportunistically cast the IHostedService to one of these lifetime event interfaces to fire the events.

Does this cover scenarios where I want to reason about stuff before any hosted services (any host) and the middleware pipeline (web host) are configured?

On 3.0, the work to configure the middleware pipeline for a webhost, when does this occur?

We're not changing the WebHostBuilder in 3.0 so but adding a generic host compatible IHostedService that will boot the server (see aspnet/Hosting#1580). IStartupFilter is still the way to run code before the server starts but if you register hosted services before the call to ConfigureWebHost, you'll run first.

When the design is created, please make sure to account for the race condition when Host calls _applicationLifetime.?.NotifyAsync() and both an IHostApplicationLifetime and an IHostedService have registered with IHostApplicationLifetime.ApplicationStarted. The IHostedService registration gets called before the IHostApplicationLifetime registration resulting in IHostedService's logging happening before the "Application has started" logging from ConsoleLifetime.

I incorrectly identified the issue as a race condition.
When reviewing the logging output, the IHostApplicationLifetime.NotifyAsync event is being fired in the reverse order of when the delegates were registered. This behavior causes the IHostServices (children) to be aware that the Application has started before the IHostApplicationLifetime (parent's lifetime) is aware.

public class SampleHostService : IHostedService
{
    private readonly ILogger<SampleHostService> _logger;
    private readonly IHostApplicationLifetime _hostLifetime;
    public SampleHostService(ILogger<SampleHostService> logger, IHostApplicationLifetime hostLifetime)
    {
        _hostLifetime = hostLifetime;
        _logger = logger;
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {
        _logger.LogInformation("Start SampleServiceHost.");
        _hostLifetime.ApplicationStarted.Register(this.OnApplicationStarted);
        return Task.CompletedTask;
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        _logger.LogInformation("Stop SampleServiceHost.");
        return Task.CompletedTask;
    }

    private void OnApplicationStarted()
    {
        _logger.LogInformation("Do some work here and immediately stop.");
        _hostLifetime.StopApplication();
    }
}

This code results in the following log entries:

info: ConsoleApp1.SampleHostService[0]
Start SampleServiceHost.
info: ConsoleApp1.SampleHostService[0]
Do some work here and immediately stop.
info: Microsoft.Hosting.Lifetime[0]
Application is shutting down...
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
Content root path: C:\ConsoleApp1\bin\Debug\netcoreapp3.0
info: ConsoleApp1.SampleHostService[0]
Stop SampleServiceHost.

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.