ASP.NET Core Introduction

What is ASP.NET Core?#

ASP.NET Core is Microsoft's framework, built on top of .NET, for building web applications and HTTP APIs. It's a full rewrite of the older ASP.NET (which only ran on .NET Framework, Windows-only) — modern ASP.NET Core is cross-platform, open-source, and one of the fastest mainstream web frameworks in independent benchmarks (like TechEmpower).

One framework covers several different application shapes:

• Minimal APIs — lightweight HTTP endpoints defined directly in Program.cs, ideal for small services and microservices (covered in depth in the next page).
• MVC with controllers — [ApiController]-attributed classes with attribute routing, the traditional structured approach, still widely used for larger APIs.
• Razor Pages / MVC views — server-rendered HTML (out of scope for this API-focused track, but built on the exact same pipeline described below).
• gRPC, SignalR, Blazor — all built as ASP.NET Core hosting models too.

Whichever style you choose, every ASP.NET Core app is built from the same two ideas: a middleware pipeline that processes every request, and a dependency injection container that supplies services to whatever needs them (covered on the .NET DI page — ASP.NET Core simply wires the same IServiceCollection into request handling automatically).

The middleware pipeline#

A middleware is a small piece of code that sits in a chain, given the chance to inspect or modify an HTTP request, and to decide whether to pass it along to the next middleware in the chain — or short-circuit and return a response immediately.

Picture it as layers of an onion: a request passes inward through each layer in order, hits your actual endpoint logic in the center, and the response then passes back outward through the same layers in reverse:

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

app.UseHttpsRedirection();  // 1. redirect HTTP → HTTPS
app.UseRouting();           // 2. determine which endpoint matches the URL
app.UseAuthorization();     // 3. check the caller is allowed to access it
app.MapGet("/", () => "Hello, ASP.NET Core!"); // 4. the endpoint itself

app.Run();

Order is not cosmetic — it's the single most common source of ASP.NET Core configuration bugs. UseAuthorization() before UseRouting() has nothing to authorize yet (routing hasn't run), and would simply never do anything useful. The full middleware model, and how to write your own custom middleware, is covered in the next-but-one page.

The minimal hosting model (.NET 6+)#

Older ASP.NET Core (through .NET 5) split configuration across two files and two methods: Startup.cs with ConfigureServices(IServiceCollection services) and Configure(IApplicationBuilder app). Since .NET 6, the minimal hosting model collapses all of that into a single Program.cs using top-level statements:

var builder = WebApplication.CreateBuilder(args);

// Equivalent of the old ConfigureServices — register services for DI
builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Equivalent of the old Configure — build the middleware pipeline
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

• WebApplicationBuilder (builder) — where you register services (builder.Services, the same IServiceCollection from the DI system) and read configuration (builder.Configuration).
• WebApplication (app) — built once builder.Build() is called; this is where you assemble the middleware pipeline and map endpoints.
• app.Environment — exposes whether you're running in Development, Staging, or Production (driven by the ASPNETCORE_ENVIRONMENT environment variable), letting you branch pipeline setup — e.g., only exposing Swagger's interactive API docs in Development.

This is the model every example in this track uses, since it's the current default for new ASP.NET Core projects (dotnet new webapi, dotnet new web).

Common mistakes#

• Registering middleware in the wrong order — e.g., UseAuthorization() before UseRouting(), which means routing hasn't matched an endpoint yet for authorization to apply to.
• Confusing "minimal APIs" (a way to define endpoints, app.MapGet(...)) with the "minimal hosting model" (a way to structure Program.cs itself) — you can use the minimal hosting model together with either minimal API endpoints or full MVC controllers.
• Forgetting app.MapControllers() (or the equivalent map call for whatever you're using) — without it, controllers/endpoints are registered with DI but never actually wired into the routing pipeline.

Interview questions#

Q: What is middleware in ASP.NET Core? A component in a chain that processes an HTTP request, decides whether to call the next component in the chain (next()), and gets a chance to act again on the way back out as the response returns. The chain is assembled, in order, in Program.cs, and that order determines exactly how a request is handled.

Q: What changed between the old Startup.cs model and the minimal hosting model? The two required methods (ConfigureServices and Configure) were collapsed into a single Program.cs using top-level statements: builder.Services.Add... replaces ConfigureServices, and calls on app (like app.Use..., app.Map...) after builder.Build() replace Configure. Functionally equivalent, just less ceremony.