Is it appropriate to use multiple hosts within one .NET program?

[jez9999]

I'm coding a bot with a web interface, and I'm wondering whether it's appropriate for me to use multiple hosts within one program to host the two separate background tasks - the bot's long-term functionality, and the web server for the web frontend. I've created a solution with a bootstrap project and separate projects for the bot and web parts, and put the following in my bootstrap project's Main:

var botHost = Bot.Service.HostSetup
    .CreateHost(args, _serviceName, _serviceDescription);
var webHost = Bot.Web.WebHostSetup
    .CreateWebHost(args);

await botHost.StartAsync();
await webHost.StartAsync();

await Task.WhenAll(new Task[] { botHost.WaitForShutdownAsync(), webHost.WaitForShutdownAsync() });

I'm not sure whether this is a supported workflow, though. The problem I'm coming across is that I want to be able to shut down the entire application from just one host. I've tried pulling in IHostApplicationLifetime into the Service host's BackgroundService and calling .StopApplication() and it only stops botHost but not webHost. Is there a way I can get this to work or am I only ever supposed to have one host for a program?

[Clockwork-Muse]

.... do you actually need a webserver backend for the web frontend? As opposed to a static web page that makes API calls to the bot backend (and yes, this can be secured appropriately).
Also, shutting down the bot this way stops the entire server process, when normally what you want to do is stop some internal task. If you shut the process this way you're going to have to restart the container (And at the point you're doing that, you may as well access your host controller and shut it down from there), as opposed to making another web api request to re-enable whatever task.

That aside, is there a reason you're not just serving this as "one" application? Just under different urls on the same host.

[jez9999]

Yeah I do like the idea of using a lightweight web server to host the web frontend, I want to have it just as regular Razor Pages not a client-heavy API calling thing.

If you're referring to .StopApplication(), shutting down the entire process is exactly what I want to do - the bot host should be able to take down the entire thing, and the web host with it. My problem is that it's not doing that, and webHost.WaitForShutdownAsync() doesn't appear to be completing even when .StopApplication() is called.

I don't understand what you're talking about with restarting the container and accessing the host controller. Could you give some examples?

I could probably put it all one one host, but it feels wrong to me because that host would presumably have to be a web host, to allow the web frontend. That makes the whole thing feel like a website with a bot service on the side, rather than what it really is, which is the inverse.

[Clockwork-Muse]

I don't understand what you're talking about with restarting the container and accessing the host controller. Could you give some examples?

What I'm getting at is that when you stop the host this way, you have to restart it from some external management system. When I said "container", I mostly meant that literally, as in a docker container. If you stop the process this way, then restarting would require you to perform a docker run again... at which point the question would be, why aren't you stopping via docker as well (or if you're not using docker, whatever equivalent system)? Whereas if you don't stop the overall process you can restart via your web api (however that's hosted).

That makes the whole thing feel like a website with a bot service on the side, rather than what it really is, which is the inverse.

... if the bot is receiving web calls from something (common for watcher webhooks), you're going to end up with a web api/site anyways. But otherwise, yes, I can see your point here. That aside, having the bot provide an API for whatever (as would be required with a static web frontend) would allow for more expansive management or integration setups, as opposed to being limited by whatever your web frontend supplies.

If you're referring to .StopApplication(), shutting down the entire process is exactly what I want to do - the bot host should be able to take down the entire thing, and the web host with it. My problem is that it's not doing that, and webHost.WaitForShutdownAsync() doesn't appear to be completing even when .StopApplication() is called.

WaitForShutdownAsync() takes a CancellationToken, which if cancelled will shut the application down. Are you able to use that instead?

[jez9999]

What I'm getting at is that when you stop the host this way, you have to restart it from some external management system. When I said "container", I mostly meant that literally, as in a docker container. If you stop the process this way, then restarting would require you to perform a docker run again... at which point the question would be, why aren't you stopping via docker as well (or if you're not using docker, whatever equivalent system)? Whereas if you don't stop the overall process you can restart via your web api (however that's hosted).

Not sure why you're assuming it's gonna be in a Docker container.

WaitForShutdownAsync() takes a CancellationToken, which if cancelled will shut the application down. Are you able to use that instead?

Interesting... I tried using that by creating a container class for a CTS and CT, using the CT as the argument, then pulling in the class and triggering the CTS to shutdown all the hosts, and it worked:

public class AppShutdownTokenProvider {
	private readonly CancellationTokenSource _tokenSource;
	private readonly CancellationToken _token;

	public AppShutdownTokenProvider() {
		_tokenSource = new();
		_token = _tokenSource.Token;
	}

	public CancellationTokenSource TokenSource => _tokenSource;
	public CancellationToken Token => _token;
}

[...]

public static IHost CreateWebHost(string[] args, AppShutdownTokenProvider shutdownToken) {
	var builder = WebApplication.CreateBuilder(args);

	builder.Services.AddTransient(_ => shutdownToken);

	[...]
}

... then, to start the hosts:

var tokenProvider = new AppShutdownTokenProvider();

var botHost = Bot.Service.HostSetup
	.CreateHost(args, tokenProvider, _serviceName, _serviceDescription);
var webHost = Bot.Web.WebHostSetup
	.CreateWebHost(args, tokenProvider);

await botHost.StartAsync();
await webHost.StartAsync();

await Task.WhenAll(new Task[] {
	botHost.WaitForShutdownAsync(tokenProvider.Token),
	webHost.WaitForShutdownAsync(tokenProvider.Token)
});

And to exit the program from within a host's service:

public class MyService : BackgroundService {
	private readonly AppShutdownTokenProvider _shutdownTokenProvider;

	public MyService(AppShutdownTokenProvider shutdownTokenProvider) {
		_shutdownTokenProvider = shutdownTokenProvider;
	}

	protected override async Task ExecuteAsync(CancellationToken stoppingToken) {
		_shutdownTokenProvider.TokenSource.Cancel();
	}
}

Does this look sensible or have I "rolled my own" version of a mechanism that already exists?

[Clockwork-Muse]

Not sure why you're assuming it's gonna be in a Docker container.

... because that's the standard modern deployment strategy for web services (even if it's abstracted, such as when running in some cloud services; eg Azure WebApps).

I tried using that by creating a container class for a CTS and CT

I believe you should be able to make this a singleton-scoped service.

Does this look sensible or have I "rolled my own" version of a mechanism that already exists?

I honestly don't know. I haven't found anything with the searching I've done (other than people just doing multi-host setups like this). But I personally am feeling like I would want to either completely split them (static web frontend + calls to api for bot service) or merge them somehow (web frontend and bot are the same web api, just under different paths).

[jez9999]

It's not a bot that offers a web API, it's a Telegram bot actually. So it's doing the polling, it's not providing any web services (the web UI is intended to just be for administration).