Overview

ASP.NET Core is Microsoft’s free, open-source framework for building web applications and HTTP services on .NET. It is a ground-up rewrite of the older ASP.NET, first released as ASP.NET Core 1.0 in June 2016, and it dropped everything that had tied the framework to Windows: no IIS requirement, no System.Web, no machine-wide installation. One codebase runs on Linux, macOS and Windows, and the HTTP server that actually answers requests, Kestrel, ships inside the framework instead of belonging to the operating system.

The framework is deliberately modular. A request passes through an ordered middleware pipeline you assemble in Program.cs, and the pieces you do not add cost nothing at runtime. Two working styles sit side by side: Minimal APIs, where a request handler is a lambda mapped to a route, and the older but still fully supported MVC and Razor Pages models, where controllers and views take the place of a single file. On top of both sit the UI frameworks, Blazor and SignalR, and the protocol layer, gRPC.

The current line is .NET 10, a Long Term Support release published in November 2025 and supported for three years, into November 2028. The latest patch at the time of writing is 10.0.13, released on 13 October 2026. This matters more than it usually does, because .NET 8 and .NET 9 both reach end of support on 10 November 2026 — an application still on either needs to move. The source lives in the dotnet/aspnetcore repository on GitHub, which carries roughly 38,500 stars and more than 11,500 forks, with the runtime and base class library in the sibling dotnet/runtime repository. Everything is MIT-licensed.

Key Features

• Kestrel — a cross-platform HTTP server with HTTP/1.1, HTTP/2 and HTTP/3 support and TLS built in, so a published application is a single process with no external web server in front of it. IIS, nginx, Caddy and Apache are still used as reverse proxies, but as a choice rather than a requirement.
• Middleware pipeline — request handling is a list of delegates you compose explicitly, which makes the order of authentication, routing, compression and error handling visible in code rather than hidden in configuration.
• Built-in dependency injection — a container with singleton, scoped and transient lifetimes is part of the framework, and the same container resolves controllers, minimal API handlers, hosted services and Blazor components.
• Layered configuration — appsettings.json, environment-specific files, environment variables, command-line arguments and user secrets merge in a defined order, and options classes bind settings to typed objects with validation.
• Minimal APIs — app.MapGet("/greet", (string name) => ...) is a complete endpoint; parameter binding, JSON serialisation and OpenAPI metadata come from the framework. .NET 10 adds request validation, Server-Sent Events and a native-AOT template to this model.
• Blazor — interactive UI written in C# rather than JavaScript, running server-side over a WebSocket, in the browser through WebAssembly, or inside a desktop and mobile shell with Blazor Hybrid.
• SignalR — persistent bidirectional connections with automatic transport fallback, which is how dashboards, chat and live notifications are usually built on this stack.
• gRPC — HTTP/2 RPC services with client and server streaming, plus JSON transcoding for clients that cannot speak protobuf.
• Security primitives — cookie, JWT bearer, OpenID Connect and WS-Federation authentication, policy-based authorisation, data protection, antiforgery tokens, HTTPS redirection and HSTS are all in the box; .NET 10 adds passkey support to ASP.NET Core Identity.
• Observability — structured logging, System.Diagnostics.Metrics counters and distributed tracing are first-class, with OpenTelemetry exporters available as NuGet packages rather than hand-written instrumentation.
• Production middleware — health checks, rate limiting, output caching, response compression, request timeouts and request decompression are shipped as middleware you add with one line.
• Testable by default — WebApplicationFactory hosts the real application in memory for integration tests, so an endpoint can be exercised end to end without a network or a running server.

What Changed in .NET 10

Most of the release notes are incremental, but four themes are worth knowing before starting a project on this version. OpenAPI generation moved to OpenAPI 3.1 with YAML output, XML documentation comments pulled into the document, and endpoint-specific operation transformers; the document generator is part of the shared framework through Microsoft.AspNetCore.OpenApi. Validation arrived for Minimal APIs, with an integration into IProblemDetailsService so a failed request returns the same problem-details shape as every other error. Server-Sent Events became a first-class response type. And Blazor picked up the largest batch of changes: the framework script is served as a fingerprinted static asset, the project template ships a reconnection UI component, improved form validation, circuit state persistence and Hot Reload for WebAssembly.

Underneath, the runtime work continues: Native AOT output is smaller and faster, JSON deserialisation can read straight from a PipeReader, JSON Patch was reimplemented on System.Text.Json, and authentication and Identity now emit metrics.

Why Use ASP.NET Core?

The strongest argument is that one language covers the whole application. Models, validation rules, business logic and the user interface can all be C#, so a validation attribute written once is enforced on the server and reused by a Blazor form instead of being reimplemented in a second language. For a small team that is a real reduction in surface area.

Performance is the second argument, and Microsoft makes it loudly: the framework is positioned as faster than other popular web frameworks in the independent TechEmpower benchmarks, and the runtime work in each release is measurable in requests per second and allocations per request. For most applications the database or the network will be the bottleneck long before Kestrel is, but the headroom means fewer servers for the same load.

The third is the support model. A Long Term Support release gets three years of patches, and the versioning policy is published in advance, so an upgrade path can be planned rather than discovered. That is a different proposition from a framework maintained by volunteers — and it also means releases are on a fixed annual cadence, which cuts both ways if you would rather not upgrade.

Finally, the ecosystem is large: NuGet carries more than 478,000 packages, the official container images are published by Microsoft in several flavours including chiseled and AOT-ready variants, and almost every integration problem has an answered question somewhere. The trade-off is that the ecosystem is Microsoft-shaped — the best tooling is Visual Studio or VS Code with the C# Dev Kit, and the documentation assumes you are comfortable with the .NET project system.

Use Cases

• JSON and REST APIs — the most common shape: a handful of minimal API endpoints, Entity Framework Core for persistence, OpenAPI for the client contract.
• Microservices and internal services — small published binaries in container images, with health checks and metrics wired for Kubernetes or a plain systemd unit.
• Line-of-business applications — server-rendered Razor Pages or Blazor Server, authenticated against an existing Active Directory or Entra ID tenant.
• Real-time features — SignalR hubs for dashboards, collaborative editing and notification feeds.
• Service-to-service RPC — gRPC for internal calls where JSON overhead and schema drift are worth avoiding.
• Background processing — BackgroundService hosted services in the same process as the web application, or as a separate worker.
• Cross-platform tools with a web UI — a Blazor Hybrid shell inside a desktop application, or a small local web interface for a CLI tool.

Getting Started

The prerequisite is the .NET SDK, version 10 for a new project. Note that Debian and Ubuntu do not package it: there is no dotnet package in Debian 13, so the SDK comes from Microsoft’s own repository at packages.microsoft.com, from the Windows and macOS installers, or from the dotnet-install script for a user-local install. The container images (mcr.microsoft.com/dotnet/sdk:10.0 and aspnet:10.0) avoid installing anything on the host at all.

From there the loop is short. dotnet new web -n Demo creates a project with a single Program.cs, dotnet run builds and starts it, and the console prints the address it is listening on. Adding an endpoint is one line, and dotnet publish -c Release produces the deployable output: framework-dependent by default, self-contained with --self-contained, or ahead-of-time compiled with -p:PublishAot=true for a small, fast-starting binary.

In production the application typically runs behind a reverse proxy that terminates TLS — nginx, Caddy or Apache on Linux, IIS or HTTP.sys on Windows — with ForwardedHeaders configured so the application sees the real client address and scheme. Nothing else is required: no application server to install, no WAR file, no shared hosting constraint. A single published directory plus the runtime, or a container image, is the whole deployment.

How It Compares

Against Spring Boot the comparison is closest: both are opinionated, convention-driven frameworks with long support windows and huge ecosystems, and both now offer ahead-of-time compilation for container workloads. Spring has the deeper enterprise integration catalogue and the JVM’s mature operational tooling; ASP.NET Core generally starts faster, uses less memory, and gives you one language across the stack if you also want the UI.

Against Laravel the difference is philosophical. Laravel is a batteries-included PHP framework that optimises for building a CRUD application quickly, with an ORM, queues, mail and an admin panel generator; ASP.NET Core is compiled and statically typed, and expects you to choose those pieces from NuGet. Laravel needs PHP-FPM and a web server; ASP.NET Core needs one process.

Against Phoenix — Elixir on the BEAM — the honest answer is that Phoenix handles vast numbers of concurrent connections more cheaply and LiveView is a genuinely different way to build interactive pages. ASP.NET Core wins on hiring pool, library breadth and tooling. Against Node.js and Express the trade is structure and type safety for a smaller ecosystem and a faster prototype; against Django it is static typing and performance for Python’s data-science adjacency.

Licence and Community

ASP.NET Core is released under the MIT licence, copyright the .NET Foundation and contributors, with no paid tier, no licence key and no restriction on commercial use. Development happens in the open on GitHub, where the ASP.NET Core repository has received contributions from thousands of developers and the wider .NET platform counts more than 100,000 contributions from around 3,700 companies. Microsoft employs a large part of the team, which is why the release schedule and support policy are dependable — and also why the roadmap is ultimately a vendor decision.

Documentation lives at learn.microsoft.com/aspnet/core and is versioned per release, with tutorials, API reference and migration guides for each major version. The community answers questions on Stack Overflow and in the repository’s discussions, the annual .NET Conf publishes recordings of every session, and the issue tracker is a workable place to report a bug. If you are coming from the old ASP.NET, Microsoft’s incremental migration guides are the place to start — a full port is rarely the right first step.