The Missing Startup.cs in .NET 6 and New Approaches to DbContext Configuration

Background and Motivation for Architectural Changes in .NET 6

With the release of .NET 6, Microsoft has significantly restructured the application startup process in ASP.NET Core. In previous versions, application configuration was typically split between two core files: Program.cs for host configuration and Startup.cs for service and middleware configuration. While this separation provided clear separation of concerns, it also increased project complexity and boilerplate code. .NET 6 simplifies application startup configuration by merging the functionality of these two files into a single Program.cs, reflecting the evolution of modern .NET development towards greater simplicity and unification.

Traditional DbContext Configuration in Startup.cs

In .NET 5 and earlier versions, developers typically configured database contexts in the ConfigureServices method of the Startup.cs file. A typical implementation looked like this:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options => 
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
    services.AddControllers();
    // Other service registrations
}

This approach relied on the dependency injection container to register the DbContext during application startup, ensuring that database context instances could be properly resolved throughout the application lifecycle. However, this pattern required developers to handle service registration and request pipeline configuration in separate methods, increasing cognitive load.

Unified Program.cs Configuration Model in .NET 6

.NET 6 introduces a new top-level statements and minimal API model that consolidates application configuration into the Program.cs file. The new configuration model uses the WebApplication builder to handle all configuration tasks uniformly. Here is a complete example of how to configure DbContext in .NET 6:

using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

// Configure database context
builder.Services.AddDbContext<ApplicationDbContext>(options => 
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

// Register other services
builder.Services.AddScoped<IUnitOfWork, UnitOfWork>();
builder.Services.AddControllers();

var app = builder.Build();

// Configure middleware pipeline
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

The core advantage of this new approach lies in its simplicity and consistency. All configuration logic is now located in the same file, using the same builder object to access configuration, services, and the application builder. It is particularly important to note that service registration is now done through the builder.Services property rather than a separate IServiceCollection parameter.

Migration Strategies and Best Practices

For projects migrating from .NET 5 to .NET 6, a gradual migration strategy is recommended. First, move all service registration logic from Startup.cs to the builder.Services section in Program.cs. Then, move middleware configuration from the Configure method to after builder.Build(). During actual migration, the following key points should be noted:

1. Changes in Configuration Sources: In .NET 6, configuration is accessed through builder.Configuration rather than the IConfiguration parameter in the Startup constructor.
2. Continuity of Dependency Injection: Although the syntax has changed, the core mechanism of dependency injection remains unchanged. All services registered via builder.Services are added to the dependency injection container during application startup.
3. Compatibility of Environment Configuration: Configuration sources such as appsettings.json and environment variables continue to work in the same way and can be accessed via builder.Configuration.

A common migration error is attempting to register services after builder.Build(). It is important to understand that all service registrations must be completed before calling builder.Build(), as this method locks the service container and builds the final application instance.

Advanced Configuration Scenarios and Extensions

For complex applications, more granular DbContext configuration may be required. The following example demonstrates how to configure multiple DbContext instances using different database providers:

builder.Services.AddDbContext<ApplicationDbContext>(options => 
    options.UseSqlServer(builder.Configuration.GetConnectionString("PrimaryConnection")));

builder.Services.AddDbContext<LogDbContext>(options => 
    options.UseSqlite(builder.Configuration.GetConnectionString("LogConnection")));

// Configure DbContext pooling for improved performance
builder.Services.AddDbContextPool<ApplicationDbContext>(options => 
    options.UseSqlServer(builder.Configuration.GetConnectionString("PooledConnection")), 
    poolSize: 128);

Additionally, developers can leverage the new configuration model to implement more flexible service registration strategies. For example, database providers can be dynamically selected based on environment variables, or in-memory databases can be used for testing in development environments.

Conclusion and Future Outlook

The removal of Startup.cs in .NET 6 represents a significant step in the evolution of the ASP.NET Core framework towards a simpler, more unified configuration model. Although this change requires some migration effort for existing projects, the benefits are substantial: reduced boilerplate code, simplified project structure, and a more intuitive configuration experience. As the .NET ecosystem continues to evolve, this minimal configuration pattern is likely to become the standard approach in future versions. Developers should actively adapt to this change, master the new configuration patterns, and fully utilize the performance improvements and development efficiency enhancements brought by .NET 6.