Generic Host

Q: What does calling host.Run() versus host.RunAsync() do, and when would you use each?

host.Run() is a blocking call that starts the host and blocks the calling thread until the application shuts down (via a shutdown signal or programmatic stop), suitable for a Program.cs's final statement in most applications. host.RunAsync() returns a Task instead, letting you await it while still doing other async work concurrently, or combine it with other awaited tasks -- useful in more complex startup scenarios where you need additional coordination logic around the host's lifetime.

Q: How do you access the built IHost's service provider after Build() to resolve services outside the normal request/injection flow, such as in Program.cs itself?

After calling builder.Build(), the resulting IHost exposes a Services property (an IServiceProvider) that Program.cs or other top-level startup code can use to resolve services directly -- commonly used for running one-time startup logic like applying database migrations or seeding initial data before calling host.Run().

Q: How do you configure the Generic Host to read configuration from a custom file format or remote source before the rest of the application starts?

Configuration sources are added to builder.Configuration before calling Build(), and since configuration is fully assembled before any services are constructed, you can add custom IConfigurationSource implementations (or built-in ones like Azure App Configuration or Key Vault providers) at this stage, and even use an already-partially-built configuration to conditionally add further sources (like only adding a remote source if a certain flag is present in local configuration).

15 questions found

How does the Generic Host's DI container differ from a full-featured third-party container in terms of the features it deliberately omits?

Advanced

The built-in container prioritizes simplicity, performance, and broad framework compatibility over advanced features found in containers like Autofac -- it deliberately doesn't support features like property/method injection, multiple constructor resolution with fallback, decorators/interceptors as first-class concepts, or child containers with fine-grained override scoping, reflecting a deliberate design philosophy that the vast majority of applications don't need this complexity, and teams that do can swap in a third-party container via UseServiceProviderFactory without losing compatibility with the rest of the Generic Host ecosystem.

// Built-in container: simple, fast, but limited feature set
builder.Services.AddScoped<IEmailSender, SmtpEmailSender>();  // constructor injection only

// For advanced features, swap the underlying container entirely:
builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());
builder.Host.ConfigureContainer<ContainerBuilder>(cb => cb.RegisterModule<AdvancedModule>());

Real-world example A team initially frustrated by the built-in container's lack of decorator support learns this is an intentional simplicity trade-off, and adopts Scrutor (a library adding decorator/scanning extensions to the built-in container) rather than switching to a full third-party container for just this one feature.

Common follow-ups: What is Scrutor and how does it add decorator support to the built-in container?;What's the performance cost of switching to a more feature-rich third-party container?

Dependency Injection;.NET CLI SDK & Project Structure (csproj)

What does calling host.Run() versus host.RunAsync() do, and when would you use each?

Beginner

host.Run() is a blocking call that starts the host and blocks the calling thread until the application shuts down (via a shutdown signal or programmatic stop), suitable for a Program.cs's final statement in most applications. host.RunAsync() returns a Task instead, letting you await it while still doing other async work concurrently, or combine it with other awaited tasks -- useful in more complex startup scenarios where you need additional coordination logic around the host's lifetime.

// Simple, most common case
var host = builder.Build();
host.Run();  // blocks here until shutdown

// More complex: awaiting alongside other async startup logic
await host.StartAsync();
await DoAdditionalSetupAsync();
await host.WaitForShutdownAsync();

Real-world example A typical Worker Service Program.cs simply calls host.Run() as its final line, while a more complex hybrid application uses host.RunAsync() combined with additional coordination logic for a custom startup sequence.

Common follow-ups: What does host.WaitForShutdownAsync() do differently from Run()?;How do you programmatically trigger a shutdown from within application code?

Generic Host;Background Services

How do you access the built IHost's service provider after Build() to resolve services outside the normal request/injection flow, such as in Program.cs itself?

Intermediate

After calling builder.Build(), the resulting IHost exposes a Services property (an IServiceProvider) that Program.cs or other top-level startup code can use to resolve services directly -- commonly used for running one-time startup logic like applying database migrations or seeding initial data before calling host.Run().

var host = builder.Build();

using (var scope = host.Services.CreateScope()) {
    var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
    await db.Database.MigrateAsync();  // one-time startup migration
}

host.Run();

Real-world example A Worker Service's Program.cs resolves a scoped DbContext once at startup (via a manually created scope) to apply pending EF Core migrations automatically before the application begins processing any background work.

Common follow-ups: Why is a manually created scope needed here instead of just calling GetRequiredService directly on host.Services?;What are the risks of running migrations automatically at every startup versus as a separate deployment step?

Entity Framework Core & Data Access;Dependency Injection

How does the Generic Host support hosting multiple independent hosted services with different failure isolation needs?

Advanced

Since each IHostedService/BackgroundService runs its own independent ExecuteAsync loop concurrently after startup, a failure in one (an unhandled exception, depending on BackgroundServiceExceptionBehavior configuration) doesn't necessarily crash unrelated hosted services running in the same host -- though by default an unhandled exception can still bring down the entire host in some configurations, so services with genuinely independent failure domains and criticality levels are sometimes better deployed as entirely separate processes/containers rather than combined into one host, trading operational simplicity (one deployable) against blast-radius isolation (one process's crash doesn't affect unrelated work).

// Two very different criticality services in the same host --
// a crash in one could still affect overall process health
builder.Services.AddHostedService<CriticalPaymentProcessor>();
builder.Services.AddHostedService<NiceToHaveAnalyticsExporter>();

// Consider separate deployments if their failure/scaling profiles genuinely differ

Real-world example A team splits a previously monolithic Worker Service (combining critical payment processing and non-critical analytics export in one host) into two separately deployed services after an analytics bug caused an unrelated outage in payment processing, illustrating the blast-radius trade-off.

Common follow-ups: What specific configuration determines whether one hosted service's crash affects others?;How do you decide when combining services into one host versus separate deployments is appropriate?

Background Services;Microservices & Distributed Architecture Patterns

How do you configure the Generic Host to read configuration from a custom file format or remote source before the rest of the application starts?

Intermediate

Configuration sources are added to builder.Configuration before calling Build(), and since configuration is fully assembled before any services are constructed, you can add custom IConfigurationSource implementations (or built-in ones like Azure App Configuration or Key Vault providers) at this stage, and even use an already-partially-built configuration to conditionally add further sources (like only adding a remote source if a certain flag is present in local configuration).

var builder = Host.CreateApplicationBuilder(args);

// Add a custom or remote source before Build()
builder.Configuration.AddAzureAppConfiguration(builder.Configuration["AppConfig:ConnectionString"]);

// All services registered afterward see the fully merged configuration
builder.Services.Configure<FeatureSettings>(builder.Configuration.GetSection("Features"));

Real-world example An application conditionally adds an Azure App Configuration source only when a connection string for it is present in local appsettings.json, letting the same codebase run correctly both with and without the centralized configuration service configured.

Common follow-ups: What's the risk of a remote configuration source being unavailable at startup?;How does provider registration order affect precedence when adding sources this way?

Configuration & Options;Secrets Management & Configuration Providers (Key Vault User Secrets)

Showing 11–15 of 15