Codebelt.Bootstrapper

Overview

Codebelt.Bootstrapper supplies the shared hosting abstractions that the Bootstrapper family builds on. It provides the conventional Startup base type, startup activation through the generic host, callback-based lifetime notifications, and environment-specific host defaults on top of Microsoft.Extensions.Hosting.

The package stays at the core-hosting layer. Concrete console, web, and worker entry-point models are added by sibling packages such as Codebelt.Bootstrapper.Console, Codebelt.Bootstrapper.Web, and Codebelt.Bootstrapper.Worker.

Key APIs

StartupRoot is the conventional startup base class. It captures IConfiguration and IHostEnvironment in its protected constructor and requires derived types to implement ConfigureServices(IServiceCollection) for service registration.

UseBootstrapperStartup<TStartup> registers a conventional startup pipeline on IHostBuilder for any TStartup : StartupRoot. The extension wires IStartupFactory<TStartup> as a singleton backed by StartupFactory<TStartup>, which creates the startup instance from the current configuration and hosting environment before calling ConfigureServices.

IStartupFactory<TStartup> exposes the activated startup instance through Instance. That makes the constructed StartupRoot available through DI after the host is built, which is useful when later code needs the same configured startup object.

UseBootstrapperLifetime replaces the default host lifetime registration with BootstrapperLifetime on both IHostBuilder and IHostApplicationBuilder. It also registers IHostLifetimeEvents, so application code can observe host start, stopping, and stopped notifications without resolving the concrete lifetime type.

IHostLifetimeEvents defines OnApplicationStartedCallback, OnApplicationStoppingCallback, and OnApplicationStoppedCallback. BootstrapperLifetime implements that contract and forwards StopAsync and WaitForStartAsync to the wrapped ConsoleLifetime while registering those callbacks against IHostApplicationLifetime.

UseBootstrapperEnvironmentDefaults adds local-development configuration behavior for both hosting models. The IHostBuilder overload adds user secrets for a StartupRoot type parameter, while the IHostApplicationBuilder overload resolves the application assembly from IHostEnvironment.ApplicationName and skips the user-secrets step when that assembly cannot be found.

Basic usage

using System.Threading.Tasks;
using Codebelt.Bootstrapper;
using Codebelt.Extensions.Xunit;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Xunit;

namespace MyProject.Tests;

public sealed class BootstrapperUsageTest : Test
{
    public BootstrapperUsageTest(ITestOutputHelper output) : base(output) { }

    [Fact]
    public async Task ShouldActivateStartupAndRaiseLifetimeCallbacks()
    {
        var started = false;
        using var host = new HostBuilder()
            .UseBootstrapperLifetime()
            .UseBootstrapperStartup<TestStartup>()
            .Build();

        var startup = host.Services.GetRequiredService<IStartupFactory<TestStartup>>().Instance;
        host.Services.GetRequiredService<IHostLifetimeEvents>().OnApplicationStartedCallback = () => started = true;

        await host.StartAsync();
        await host.StopAsync();

        TestOutput.WriteLine($"Started: {started}, ServicesConfigured: {startup.ServicesConfigured}");

        Assert.True(started);
        Assert.True(startup.ServicesConfigured);
    }

    private sealed class TestStartup : StartupRoot
    {
        public TestStartup(IConfiguration configuration, IHostEnvironment environment) : base(configuration, environment) { }

        public bool ServicesConfigured { get; private set; }

        public override void ConfigureServices(IServiceCollection services)
        {
            ServicesConfigured = true;
        }
    }
}

Use this pattern when you want a generic host to keep a conventional Startup class while still surfacing host lifetime notifications through DI. It matters because the core package coordinates startup activation and lifecycle callbacks without forcing you into one of the concrete console, web, or worker packages.

Installation

dotnet add package Codebelt.Bootstrapper

Usage guidance

Use Codebelt.Bootstrapper when you want the shared conventions behind the Bootstrapper family, especially StartupRoot, startup activation, and lifetime callbacks on top of the generic host. Choose Codebelt.Bootstrapper.Console, Codebelt.Bootstrapper.Web, or Codebelt.Bootstrapper.Worker when you need a concrete application model, or stay with plain Microsoft.Extensions.Hosting configuration when a custom StartupRoot abstraction adds no value.