Why Microsoft Merged Startup.cs and Program.cs in .NET 6: A Complete Explanation

With .NET 6, Microsoft introduced a modern, simplified hosting model that significantly changes how ASP.NET Core applications are bootstrapped. One major architectural shift was the merging of Startup.cs into Program.cs.

This change is not random — it solves real problems and streamlines application startup, configuration, and dependency injection.

1️⃣ Background: How It Worked Before (.NET 5 and Earlier)

Before .NET 6, an ASP.NET Core project contained two main startup files:

1. Program.cs

Configured the Host
Bootstrapped the application
Called CreateHostBuilder
Loaded Startup.cs

2. Startup.cs

Contained ConfigureServices() → Dependency Injection
Contained Configure() → Middleware pipeline

This pattern worked well but introduced fragmentation, unnecessary files, and complexity for beginners.

2️⃣ Why Merge Startup.cs and Program.cs?

Microsoft aimed to evolve .NET into a more modern, minimal, and developer-friendly platform.
The merge solves multiple issues at once.

Reason 1: Simplify Application Bootstrapping (Minimal Hosting Model)

.NET 6 introduced the Minimal Hosting Model, where the entire app can be configured using a small, clean Program.cs file:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();

var app = builder.Build();
app.MapControllers();

app.Run();

No more separate hosting classes or lengthy boilerplate code.

This makes .NET apps feel more like Node.js, Express, Python Flask, and Go.

Reason 2: Reduce Boilerplate & Improve Readability

Old structure included:

Program.cs
Startup.cs
CreateHostBuilder
UseStartup
WebHostDefaults

Beginners found this confusing.

The new unified Program.cs removes complexity and makes the project easier to read.

Before: 4–6 lines just to build a host.

After: 1 line:

var app = builder.Build();

Reason 3: Better Alignment with Modern Web Frameworks

Modern frameworks prefer single-file startup:

Node.js → index.js
Express → server.js
Flask → app.py
Spring Boot → Application.java

Merging Program.cs and Startup.cs aligns .NET with global developer expectations.

Reason 4: Flexibility — Everything can be configured in the order you want

In old Startup.cs:

Services configured in one file
Middleware configured in another
Host configured in Program.cs

This "split configuration" created ordering problems.

Now everything is in one place, so developers can:

Add services anytime
Configure middleware in any order
Register features dynamically

Reason 5: Minimal APIs Support

Minimal APIs were introduced in .NET 6.

Example:

var app = WebApplication.CreateBuilder(args).Build();

app.MapGet("/hello", () => "Hello World!");

app.Run();

This approach requires a merged Program.cs — minimal APIs don’t work cleanly across multiple startup files.

Reason 6: Better Performance & Faster Startup

With Startup.cs removed, .NET can:

Build the hosting pipeline faster
Reduce reflection
Simplify runtime initialization
Improve startup latency (important for serverless & cloud apps)

Reason 7: Consistency Across All .NET App Types

.NET 5 had different boot models:

ASP.NET Core → Program.cs + Startup.cs
Console apps → Program.cs only
Worker service → HostBuilder pattern
Web API → Startup + Program

Now, every .NET 6+ app uses the same model, improving consistency.

3️⃣ What Actually Changed Internally?

IHostBuilder and WebHostBuilder merged into one pipeline.
You no longer call .UseStartup<Startup>().
Middleware and dependency injections are defined directly in Program.cs.
WebApplicationBuilder replaced HostBuilder + Startup architecture.

4️⃣ Is Startup.cs Still Allowed?

Yes.
You can still use it if you want:

builder.Host.UseStartup<Startup>();

But Microsoft recommends moving forward with the new model.

5️⃣ Pros and Cons of Merging Startup.cs Into Program.cs

✔ Pros

1. Cleaner, shorter, modern code

Developers understand the startup flow quickly.

2. One place for everything

DI, services, routing, middleware → all in Program.cs.

3. Supports Minimal API Architecture

The future of lightweight microservices.

4. Less boilerplate

Easier onboarding for new developers.

5. More flexible application configuration

Dynamic or conditional configuration is easier.

❌ Cons

1. Can become a “God File”

If not structured properly, Program.cs may become very long.

2. Some developers still prefer separation

Teams used to Startup.cs might need adjustment time.

3. Harder to organize very large projects

But can be fixed using:

Extension methods
Partial classes
Modular configuration

Summary

Microsoft merged Startup.cs and Program.cs in .NET 6+ to:

Simplify the hosting model
Reduce boilerplate
Support Minimal APIs
Improve performance
Make .NET more approachable and modern
Unify the startup experience across all project types

The result is a cleaner, faster, more flexible way to build ASP.NET Core applications, in line with modern development trends.