If you run production software on .NET, November 2025 was not just another launch week — it was the moment the road ahead got clearer. .NET 10 shipped as a Long Term Support (LTS) release on 11 November 2025, with patches supported through 14 November 2028. At the same time, .NET 8 and .NET 9 both hit end-of-support on 10 November 2026.
That combination forces a real decision. Stay on a version with months left, jump to .NET 11 previews for bleeding-edge language features, or standardise on .NET 10 and get three years of breathing room. At NovIqra we build client APIs, internal platforms, and products like NoviMeet on ASP.NET Core — so we have been living on .NET 10 since the RC builds. This post is what we wish someone had handed us before the first upgrade: not a marketing slide, but a practical map of what actually changed and where it shows up in day-to-day work.
First things first: what .NET 10 actually is
.NET 10 is the whole stack — runtime, base libraries, SDK, ASP.NET Core 10, EF Core 10, MAUI, tooling. It ships with C# 14 (not C# 15 — that rides with .NET 11 previews). Microsoft positions it as the stable choice for production: LTS, monthly patch Tuesday updates, and the same quality bar as STS releases, just with a longer support contract.
As of mid-2026, current patch level is 10.0.9 (June 2026). If you are starting a new enterprise project today and want support through 2028 without chasing yearly upgrades, .NET 10 is the obvious baseline. If you are experimenting with union types and closed hierarchies, that is C# 15 / .NET 11 territory — different timeline, different risk profile.
Performance: the boring wins that add up
Every .NET release claims to be the fastest yet. .NET 10 is no exception, but a few changes are concrete enough to point at rather than hand-wave about benchmarks.
The JIT got better at inlining and devirtualization — meaning hot paths through interfaces or virtual calls are more likely to collapse into straight-line code at runtime. For service-heavy APIs that process thousands of small requests, that shows up as lower CPU and slightly tighter latency distributions, not necessarily a dramatic single-request speedup.
Stack allocation improvements let the runtime place more value types and even some reference types on the stack when escape analysis proves it is safe. Less GC pressure in tight loops. Hardware side: AVX10.2 on recent Intel chips and Arm64 SVE on Arm — relevant if you deploy on varied cloud SKUs. The Arm64 write-barrier work is especially interesting for GC-heavy workloads: Microsoft reported roughly 8–20% shorter GC pause times in some scenarios.
NativeAOT keeps maturing — smaller deployable sizes, better compatibility for minimal APIs
and the webapiaot template. We do not AOT everything (reflection-heavy enterprise apps still
favour JIT), but edge microservices and CLI tools benefit. If you have a small API that boots in a
container and should start in milliseconds, .NET 10 is worth a second look here.
C# 14 — language changes you will actually type
C# 14 is not a revolution. It is the kind of release that removes small frictions you did not realise you had until they are gone.
Field-backed properties
This one spread through our codebase fast. Before C# 14, the moment you needed validation in a property
setter you jumped from a clean auto-property to a backing field, a constructor pattern, or a boilerplate
_name field. Now the compiler gives you a field keyword that refers to the
generated backing field:
public string Title
{
get => field;
set => field = value?.Trim() ?? string.Empty;
}
It reads naturally. Trim on set, guard clauses, lazy defaults — without the ceremony. For DTOs and domain entities across hundreds of projects, that is a surprising amount of deleted lines.
Extension members (the extension block)
Extension methods were always a bit awkward for properties. C# 14 adds extension blocks so you
can attach instance and static extension properties and methods to types you do not own — including
interfaces. List helpers, string normalisation, guard extensions on HttpContext — the pattern
finally matches how people were already trying to structure utility code.
Null-conditional assignment (?=)
Small syntax, big readability win in service code:
cacheEntry?.Value = ComputeExpensiveResult();
You were probably writing an if (cacheEntry != null) block before. Now the intent is visible
in one line. Pairs well with nullable reference types on API models.
Everything else worth knowing
First-class Span<T> conversions reduce friction in performance-sensitive parsing.
Partial properties and constructors complete the partial-type story from C# 13. Lambda parameters can use
ref/out/in without spelling out types. Collection expressions gained
spread and params extensions. None of these will make a stand-alone blog post on their own, but together
they make C# feel less like you are fighting the compiler for reasonable code.
ASP.NET Core 10 — where we spend most of our time
This is the section that mattered most for NovIqra client work. Web APIs and multi-tenant SaaS backends do not care about MAUI updates — they care about auth, validation, observability, and deployability.
Built-in validation on Minimal APIs
For years, Minimal API endpoints either skipped validation or pulled in third-party libraries. .NET 10 adds
AddValidation() so query strings, headers, and bodies validate through DataAnnotations (and
nested objects/collections work). Failed validation returns 400 Bad Request with problem
details automatically.
We have been gradually moving internal admin endpoints to Minimal APIs — lightweight, fast to stand up. Built-in validation removed a whole category of “do we add FluentValidation here or not?” debates for simpler surfaces. Complex domain rules still belong in handlers; but format, required fields, and range checks? Let the framework handle it.
OpenAPI 3.1 and documentation that writes itself
OpenAPI generation now targets 3.1 with better JSON Schema alignment. XML doc comments on
controllers and DTOs flow into the generated spec — summary, description, response context via enhanced
ProducesResponseType. You can serve YAML OpenAPI for human review. If your team treats the
OpenAPI file as the contract with frontend or external integrators (we do), this saves a maintenance layer
that used to drift out of sync.
Passkeys in ASP.NET Core Identity
Passwordless login via WebAuthn/FIDO2 is no longer a science project you bolt on yourself. Identity templates include passkey registration and sign-in; Blazor Web App templates ship with management UI. For B2B products where IT departments push MFA and phishing-resistant auth, this is a credible path without outsourcing auth to a third party — though you still need the operational pieces (recovery flows, device management policy).
Memory pool eviction for long-running apps
Services that stay up for weeks — background workers, notification dispatchers, always-on APIs — sometimes retained memory in pools that never shrank. Automatic eviction returns idle pooled memory to the OS. You will not notice on a stateless API that restarts every deploy; you will notice on that one Windows service everyone forgot was still running on a VM since 2024.
Server-Sent Events in Minimal APIs
TypedResults.ServerSentEvents() makes SSE a first-class return type. Real-time dashboards,
progress streams, live meeting status — scenarios where WebSockets are heavy but polling is ugly. NoviMeet’s
notification and activity patterns are a natural fit; SSE is simpler to proxy through corporate firewalls
than bidirectional sockets for many enterprise deployments.
Blazor improvements (if you are in that world)
Even when our primary UI is Angular, several clients run Blazor for internal tools. .NET 10’s
[PersistentState] attribute, circuit pause/resume, WebAssembly preloading, and default response
streaming in WASM HttpClient address real pain: users losing form state on reconnect, slow
first paint, large JSON payloads buffering entirely in memory. Form validation is now source-generated and
AOT-friendly. Playwright integration through WebApplicationFactory lowers the friction for
automated UI tests — still not free, but less bespoke harness code.
The SDK: file-based apps and container workflows
One of the underrated .NET 10 stories is the SDK, not the runtime.
File-based apps let you write a Program.cs (or .cs file) without
a full .csproj for scripts and utilities — then publish and even target NativeAOT from that
single file. We have replaced a handful of one-off migration scripts and data-fix tools that were “temporary”
console projects nobody wanted to maintain in the solution. dotnet run YourScript.cs feels closer
to how Python or Node devs expect small automation to work.
Container tooling improved: console apps can produce container images natively, platform-specific .NET tools
work more predictably, dotnet tool exec runs one-shot tools without permanent install. For teams
deploying to Azure Container Apps or Kubernetes, the pipeline gets shorter — fewer Dockerfiles written by hand
for simple services.
Microsoft.Testing.Platform integration in dotnet test is another quality-of-life
shift for larger solutions running thousands of tests in CI.
Libraries: security and networking that age well
Post-quantum cryptography expanded — ML-DSA, ML-KEM, Windows CNG integration, composite hybrid algorithms. Most teams will not flip this on tomorrow, but compliance-driven clients in finance and government are already asking what the migration path looks like. Having it in the BCL means you are not hunting preview NuGet packages when procurement mandates catch up.
WebSocketStream wraps WebSocket usage in a familiar Stream API — less callback spaghetti.
TLS 1.3 on macOS closes a long-standing gap for cross-platform clients. JSON serialization
can now reject duplicate properties on deserialize (silent overwrite bugs, begone) and supports
PipeReader for high-throughput ingestion. Small features individually; collectively they reduce
the “we need a custom layer for that” impulse.
EF Core 10 — data layer highlights
EF Core 10 is a solid incremental release rather than a rewrite. Named query filters let you attach multiple filters per entity and disable them selectively — useful for multi-tenant apps where “soft delete” and “tenant scope” used to fight over one global filter. LINQ improvements and Cosmos DB updates matter if you are on Azure; vector search support aligns with AI features below. SQL Server 2022 compatibility level 160 as default keeps newer deployments aligned with modern engine behaviour.
The EF1004 analyzer warns when you call ToAsyncEnumerable() on an
IQueryable — because it runs synchronously under the hood and people assume async means
non-blocking. We have seen that mistake in code review more than once.
AI in .NET 10 — powerful, optional, easy to overbuild
Microsoft went hard on AI for this release. Honest take: not every line-of-business app needs a multi-agent orchestration layer on day one. But the plumbing is now first-class, which changes how you prototype.
Microsoft.Extensions.AI gives you IChatClient — swap OpenAI, Azure OpenAI,
Ollama, GitHub Models without rewriting call sites. Middleware for caching and telemetry hooks in cleanly.
If you are adding a “summarise this meeting MOM” feature or a support chatbot, you start from abstractions
instead of vendor SDKs scattered through controllers.
The Microsoft Agent Framework (Semantic Kernel + AutoGen converged) targets multi-step
workflows — sequential agents, handoffs, group chat patterns. Template: dotnet new aiagent-webapi
scaffolds an ASP.NET Core host with a dev UI for testing agents. Powerful for document processing pipelines
or internal copilots; overkill for wrapping a single prompt.
Model Context Protocol (MCP) support means agents can call tools and data sources through
a standard protocol — databases, file systems, internal APIs. dotnet new mcpserver gets you
started. This is the piece to watch if you are building AI that must touch real business systems safely, not
just chat.
Aspire 13 — great if you are all-in on distributed local dev
Aspire (formerly .NET Aspire, now just Aspire) orchestrates APIs, frontends, databases, and containers with observability baked in. Version 13 ships with .NET 10: simpler AppHost SDK, polyglot support for Python/JS services alongside .NET, static frontend hosting, parallelised deploys. We have not moved every client to Aspire — many already have Docker Compose or cloud-native tooling — but for greenfield microservice stacks on Azure, the developer inner loop is noticeably smoother than wiring Serilog, health checks, and service discovery by hand for the fifth time.
How we would plan an upgrade (if you have not yet)
If you are still on .NET 6 or 7, stop reading feature lists and start with support dates — those runtimes are already past EOL. .NET 8 → 10 is the common jump in 2026:
- Run
dotnet outdatedand the portability analyzer on your solution. Fix package blockers before touching TFMs. - Bump to
net10.0on a branch, build, fix breaking changes (Microsoft publishes a consolidated breaking-changes doc per release). - Regression-test auth and serialisation — where upgrades usually surprise you.
- Adopt C# 14 incrementally — field-backed properties and
?=do not require a big bang refactor. - Turn on new ASP.NET features per service — validation and OpenAPI on new endpoints first, not a wholesale rewrite.
- Deploy to staging, watch memory and GC metrics — validate the runtime wins on your actual traffic shape, not generic benchmarks.
For products we maintain — NoviMeet’s API is on .NET 8 today — .NET 10 is the target before .NET 8 support ends. LTS alignment beats chasing previews unless a specific C# 15 feature blocks a release.
What we are not upgrading for
Clarity matters. .NET 10 will not replace a well-architected Angular or React frontend. It will not fix a poorly modelled database. Agent Framework will not make a vague requirements document implement itself. MAUI updates are irrelevant if you do not ship mobile. Know which bucket your pain lives in before upgrading for the headline feature.
Bottom line
.NET 10 is the production anchor for 2026–2028: LTS until November 2028, shipped 11 November 2025, paired with C# 14, meaningful ASP.NET Core quality-of-life, a faster runtime, and AI primitives that are finally integrated rather than bolted on. The features that earned our attention first were built-in Minimal API validation, OpenAPI 3.1 with doc comments, file-based apps for tooling, and the steady runtime/GC improvements that show up under real load.
If you are building enterprise software, REST APIs, or SaaS on Microsoft’s stack, this is the version to standardise on now — and keep an eye on .NET 11 previews separately when you want to experiment with the next language wave without betting production on it.