Overview
Codebelt Bootstrapper wraps Microsoft.Extensions.Hosting with a conventional Startup model, host-lifetime integration, and environment defaults that can be reused across several application styles. The repository then layers concrete entry-point models on top of that core so console programs, ASP.NET Core apps, and worker services can all follow the same bootstrapper conventions without rebuilding host setup from scratch.
Concepts
The packages in this repository share one idea: keep host construction predictable, then adapt that core host model to the execution surface of the application.
Startup activation through the host
At the center is Codebelt.Bootstrapper, which introduces StartupRoot, UseBootstrapperStartup<TStartup>, and IStartupFactory<TStartup>. Those APIs move startup construction into the host so configuration, environment data, and service registration are resolved through one pipeline instead of scattered across Program code. The concrete packages reuse that model with specialized startup bases such as ConsoleStartup, WebStartup, and WorkerStartup, so the same activation pattern survives even when the application model changes.
Lifetime callbacks and shutdown coordination
The repository also treats host lifetime as an explicit extension point. Codebelt.Bootstrapper replaces the default lifetime with BootstrapperLifetime and exposes IHostLifetimeEvents so application code can observe started, stopping, and stopped transitions through DI. That shared lifetime model becomes especially important in Codebelt.Bootstrapper.Console, where hosted services run the program work and request shutdown when RunAsync completes, but the same lifetime wiring is also applied by the web and worker entry points.
Console work as hosted execution
Codebelt.Bootstrapper.Console adapts the core abstractions to long-running or command-style console applications. ConsoleProgram<TStartup>, UseConsoleStartup<TStartup>(), MinimalConsoleProgram, and MinimalConsoleProgram<TProgram> turn console execution into hosted-service work, which means the program's RunAsync logic participates in host startup, graceful shutdown, and the bootstrapper lifetime pipeline instead of being called manually from Main.
Web startup with an explicit pipeline hook
Codebelt.Bootstrapper.Web keeps the same startup-centered model for ASP.NET Core applications while adding a clear HTTP pipeline boundary. WebProgram<TStartup> and MinimalWebProgram apply the bootstrapper lifetime and environment defaults before the app is built, and WebStartup adds ConfigurePipeline(IApplicationBuilder) alongside service registration. That makes middleware and endpoint composition a first-class startup concern rather than an unrelated step beside the host bootstrap logic.
Worker host composition without web-specific plumbing
Codebelt.Bootstrapper.Worker applies the same conventions to background-service hosts. WorkerProgram<TStartup>, WorkerStartup, and MinimalWorkerProgram focus on host construction and hosted-service registration rather than HTTP pipeline concerns, which keeps worker applications aligned with the bootstrapper model while staying specific to generic-host service execution.
Usage guidance
Start with Codebelt.Bootstrapper when you need the shared abstractions such as StartupRoot, startup activation, lifetime callbacks, or environment defaults, but not a concrete application model. Move to Codebelt.Bootstrapper.Console, Codebelt.Bootstrapper.Web, or Codebelt.Bootstrapper.Worker only when the application surface needs their specific entry-point and lifecycle adapters.
Avoid pulling in a more specialized package just to get the shared host extensions. The smaller package is the better fit when all you need is the core host pipeline, while the console, web, and worker packages are for cases where their hosted execution model, pipeline hook, or service-host setup changes how the application starts and stops.