.NET 11 is getting closer to its final release, and the first Release Candidate is now available.
Microsoft released .NET 11 Release Candidate 1 (RC1) on September 8, 2026, bringing a wide range of updates across the .NET runtime, SDK, ASP.NET Core, Blazor, C#, libraries, Entity Framework Core, containers, and other parts of the ecosystem.
For developers who work with ASP.NET Core, Blazor, APIs, or enterprise applications, this is an important stage of the .NET 11 release cycle.
But there is a practical question behind all the new features:
What does .NET 11 actually mean for developers, and what should you pay attention to before the final release?
This article looks at the most relevant changes in .NET 11 and explains how they may affect real-world .NET development.
RC1 stands for Release Candidate 1.
It means the release is approaching its final form, although Microsoft can still make changes before the general availability release.
.NET 11 RC1 includes updates across:
.NET Runtime
ASP.NET Core
Blazor
C# 15
Entity Framework Core
.NET SDK
MSBuild
NuGet
Container tooling
.NET libraries
Windows Forms
.NET MAUI
Microsoft describes the RC1 release as a go-live release, meaning it comes with production support during the release candidate period.
For developers who want to experiment with .NET 11 before the final release, this makes RC1 significantly more useful than an early preview.
One of the biggest developer-facing changes in .NET 11 is C# 15.
C# 15 introduces several language features, including:
Union types
Collection expression arguments
Closed hierarchies
Extension indexers
Labeled break and continue
Memory safety improvements
These features are designed to make C# more expressive while providing better ways to model application code.
Let's look at some of the more interesting changes.
Union types are one of the most interesting additions in C# 15.
A union represents a value that can be one of several defined types.
For example:
facebook
linkedin
instagram
twitter
public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);
public union Pet(Cat, Dog, Bird);
Now a Pet can represent a Cat, Dog, or Bird.
You can then use pattern matching:
Pet pet = new Dog("Rex");
string name = pet switch
{
Dog dog => dog.Name,
Cat cat => cat.Name,
Bird bird => bird.Name
};
The compiler can ensure that all defined cases are handled.
This can be particularly interesting for API response models and domain models where a value has a limited set of possible types.
Union types become particularly interesting when building APIs.
Consider an endpoint that can return either:
A successful response
A validation error
A not-found result
Traditionally, developers may represent these possibilities using several patterns.
Union types provide another way to model the possible results explicitly.
This can make application contracts easier to understand.
ASP.NET Core 11 also supports C# union types in areas including Minimal APIs, MVC, SignalR, Blazor JavaScript interop, persistent component state, and prerendered component parameters.
That makes this more than a language feature. It can become useful across the web development stack.
C# already has collection expressions:
string[] names = ["John", "David", "Sarah"];
C# 15 extends collection expressions by allowing constructor or factory arguments.
For example:
List<string> names =
[
with(capacity: 100),
"John",
"David",
"Sarah"
];
You can also specify a comparer when creating certain collections.
For example:
HashSet<string> names =
[
with(StringComparer.OrdinalIgnoreCase),
"John",
"DAVID",
"john"
];
This provides more control while keeping the collection expression syntax concise.
C# 15 also introduces closed hierarchies.
This is useful when you want to model a known set of derived types.
For domain-driven applications, API contracts, state machines, and business workflows, being able to express a closed set of possibilities can make the code easier to reason about.
Combined with pattern matching and union types, this gives developers more tools for modelling domain rules directly in C#.
For web developers, ASP.NET Core 11 is one of the most important parts of this release.
The current ASP.NET Core 11 updates include improvements to:
Blazor
Minimal APIs
SignalR
OpenAPI
Authentication
Validation
Security
Web Workers
Client-side rendering
API development
Several of these changes are particularly relevant to modern business applications.
Blazor continues to receive significant attention in ASP.NET Core 11.
The latest updates include improvements to:
Component rendering
Forms
Validation
Web Workers
Browser configuration
Navigation
Client-side behavior
Container support
For developers building interactive business applications, these changes are worth watching.
One useful improvement is client-side validation for Blazor Static Server-Side Rendering.
Previously, server-rendered forms could require a round trip to the server before validation feedback was displayed.
ASP.NET Core 11 adds client-side validation support for Static SSR forms while continuing to use the .NET model as the source of validation rules.
This provides a more responsive form experience without requiring the entire application to become interactive.
For business applications with large numbers of forms, this can be a meaningful improvement.
Blazor forms also receive support for asynchronous validation.
This matters when validation requires an external operation.
For example, imagine an application where a user enters a product code:
Product Code
↓
Validate Format
↓
Check Database
↓
Check Availability
↓
Display Result
Some validation rules cannot be determined from the local model alone.
ASP.NET Core 11 adds support for asynchronous validation scenarios, including database lookups and remote API calls.
This can be particularly useful in enterprise applications.
One of the most interesting additions in ASP.NET Core 11 is the introduction of experimental Blazor AI components.
The new Microsoft.AspNetCore.Components.AI package provides building blocks for AI-powered user interfaces.
The initial components target scenarios such as:
Streaming chat
Rich text
Tool rendering
Human approval flows
Typed UI state
Shared UI state
Predictive UI state
This is particularly interesting because AI functionality is increasingly becoming part of ordinary business applications.
Imagine a CRM application where an AI assistant can:
User
↓
AI Assistant
↓
Read Customer Context
↓
Suggest Action
↓
Ask for Approval
↓
Execute Tool
Blazor's component model provides a natural place to integrate this type of interactive experience.
However, there is an important distinction:
The Blazor AI components are experimental and should not be treated as a finalized production API yet.
For production systems, developers should carefully evaluate the package maturity and API stability before depending on it.
ASP.NET Core 11 also includes finalized APIs for refreshing authentication in SignalR.
This is relevant for applications where users maintain long-lived real-time connections.
Examples include:
Live dashboards
Trading applications
Monitoring systems
Collaboration software
Notification systems
Real-time business applications
Authentication state can change during a long-lived connection, so having better support for refreshing authentication credentials can simplify these scenarios.
The SignalR TypeScript client also receives authentication refresh support.
ASP.NET Core 11 improves how Minimal API endpoint filters interact with parameter-binding failures.
Endpoint filters can now observe certain binding failures and customize the response.
For APIs that require consistent error formats, this can make centralized validation and error handling easier to implement.
For example, an API can maintain a consistent response structure:
{
"success": false,
"message": "Invalid request",
"errors": []
}
rather than allowing different parts of the application to produce unrelated error formats.
OpenAPI remains an important part of modern ASP.NET Core API development.
.NET 11 continues to improve the integration between ASP.NET Core and OpenAPI.
This matters because API documentation is no longer just a development convenience.
For modern applications, OpenAPI can be used by:
Frontend developers
Mobile developers
Integration teams
API clients
Automated tooling
Testing systems
Keeping API contracts accurate and machine-readable becomes increasingly important as applications grow.
.NET 11 also improves the Blazor Web Worker experience.
The Web Worker project template has been renamed to the Blazor Web Worker template to make its purpose clearer.
The generated worker client also gains support for:
InvokeVoidAsync
Cancellation
Timeouts
Web Workers can be useful when browser-side work should be moved away from the main UI thread.
For example:
Main UI Thread
│
├── User Interaction
├── Rendering
│
└── Web Worker
│
├── Heavy Processing
├── Data Processing
└── Background Work
This can help keep interactive applications responsive when performing suitable client-side operations.
.NET 11 introduces a new development server for standalone Blazor WebAssembly applications through Microsoft.AspNetCore.Components.Gateway.
The Gateway replaces the previous Microsoft.AspNetCore.Components.WebAssembly.DevServer for serving standalone Blazor WebAssembly applications.
For teams working with standalone Blazor WebAssembly projects, this represents an important tooling change.
Existing applications can adopt the Gateway by referencing the appropriate package.
The Blazor Web App project template now includes container support options in Visual Studio.
This makes it easier to package Blazor applications for container-based deployment environments.
A typical deployment can look like:
Blazor Web App
↓
Container Image
↓
Container Registry
↓
Cloud / Kubernetes
This is particularly relevant for teams already using Docker, Kubernetes, Azure Container Apps, or similar infrastructure.
The SDK also receives several improvements.
Among them are:
Smaller SDK installers on Linux and macOS
Improved analyzers
Solution filter support from the CLI
Better file-based applications
Native AOT support for file-based applications
dotnet run -e
Improved dotnet watch
Aspire integration
Improved CLI Native AOT support
For developers who spend a lot of time in the command line, these improvements can make the development workflow smoother.
dotnet run -eA small but useful addition is the ability to pass environment variables directly through dotnet run.
For example:
dotnet run -e ASPNETCORE_ENVIRONMENT=Development
This can be convenient when testing different application environments without changing configuration files.
Performance continues to be an important focus of the .NET platform.
Microsoft has highlighted hundreds of performance improvements in .NET 11 across the runtime and libraries.
These improvements cover areas such as:
JIT compilation
Garbage collection
Collections
Reflection
JSON
Networking
Runtime execution
Native AOT
However, developers should avoid assuming that upgrading automatically makes every application faster.
Real application performance still depends heavily on architecture.
For example:
Slow Query
↓
Database
↓
API
↓
Serialization
↓
Network
↓
UI
If the database query takes two seconds, a runtime optimization may not make the user experience acceptable.
Performance should always be measured against the actual workload.
Entity Framework Core continues to evolve alongside .NET.
For applications using EF Core, upgrading should be evaluated separately from simply changing the .NET target framework.
Before upgrading a production application, check:
Database provider compatibility
Migration behavior
Generated SQL
LINQ translation
Query performance
Third-party extensions
Tracking behavior
Transactions
Concurrency
A newer EF Core version can provide improvements, but application-specific database testing remains essential.
For a production application, the answer depends on the project's requirements and risk tolerance.
RC1 is much closer to the final release than an early preview and includes go-live support.
However, it is still a Release Candidate, not the final general availability release.
For an existing production application that is stable on an LTS version, waiting for the final release may be a reasonable approach unless you have a specific reason to test or adopt RC1.
For development and testing, RC1 provides an excellent opportunity to identify compatibility issues before the final release.
For a new project that needs to ship before the final release, RC1 may be worth evaluating.
However, for a project that does not need .NET 11-specific functionality immediately, developers should consider whether using a currently stable release better matches the project's timeline.
The decision should consider:
Release schedule
Required features
Package compatibility
Hosting environment
Team experience
Production deadline
Upgrade strategy
A framework should support the project timeline rather than dictate it.
One of the natural questions is how .NET 11 compares with .NET 10.
| Area | .NET 10 | .NET 11 |
|---|---|---|
| Current status | Stable | RC1 |
| C# | C# 14 | C# 15 |
| ASP.NET Core | 10 | 11 |
| Blazor | Modern Blazor | Additional Blazor improvements |
| Runtime | Performance improvements | Further performance work |
| AI UI | Existing ecosystem | Experimental Blazor AI components |
| Long-term choice | Stable LTS | Release candidate at present |
For a production application today, the stability of the release should be considered alongside the features you need.
.NET 11 will become a more natural target once the final release is available.
If you are preparing for .NET 11, don't focus only on memorizing new syntax.
A practical learning path would be:
Pay particular attention to:
Union types
Closed hierarchies
Collection expression arguments
Extension indexers
Memory safety improvements
Focus on:
Minimal APIs
OpenAPI
Authentication
Authorization
SignalR
Validation
Error handling
Focus on:
Rendering modes
Static SSR
Forms
Async validation
Web Workers
AI components
State management
New language features cannot compensate for poor architecture.
Continue focusing on:
SOLID
Dependency Injection
Repository patterns where appropriate
CQRS where justified
Clean separation of responsibilities
Database design
Caching
Testing
Observability
The framework changes.
Good software engineering principles remain important.
A modern business application could look like:
Blazor / MVC / React
↓
ASP.NET Core
↓
Application Layer
↓
Business Logic
↓
Infrastructure Layer
↓
Entity Framework Core
↓
PostgreSQL / SQL Server
AI functionality can be introduced as another application capability:
Web UI
↓
Application Services
↓
┌─────────────┴─────────────┐
│ │
Business Logic AI Services
│ │
└─────────────┬─────────────┘
↓
Database
This separation allows AI features to evolve without turning the UI into the place where every responsibility lives.
A new .NET release can create pressure to immediately rewrite existing applications.
That is rarely necessary.
You don't need to:
Rewrite a stable application just because .NET 11 exists.
Adopt every C# 15 feature.
Use experimental Blazor AI components in production without evaluating their maturity.
Replace MVC with Blazor without a clear requirement.
Rewrite database queries without measuring them.
Adopt Native AOT simply because it is available.
Instead:
Identify the problem first, then choose the feature that solves it.
.NET 11 RC1 is an important milestone in the next generation of .NET development.
The release brings improvements across the runtime, SDK, ASP.NET Core, Blazor, C#, APIs, containers, and developer tooling.
For C# developers, C# 15 and union types are among the most interesting language developments.
For ASP.NET Core developers, improvements to Minimal APIs, OpenAPI, SignalR, validation, and authentication are particularly relevant.
For Blazor developers, Static SSR validation, asynchronous validation, Web Workers, browser configuration, and experimental AI components make the release especially interesting.
But not every feature needs to be adopted immediately.
For existing applications, measure the value of upgrading against compatibility, stability, and project requirements.
For new applications, evaluate the release based on the project's timeline and the maturity of the features you plan to use.
The most important lesson is simple:
Don't adopt .NET 11 because it is new. Adopt the parts of .NET 11 that solve real problems in your application.
.NET 11 RC1 is the first Release Candidate of .NET 11. Microsoft released it on September 8, 2026. It is close to the final release and includes go-live support.
C# 15 is the default language version for projects targeting .NET 11.
C# 15 introduces features including union types, closed hierarchies, collection expression arguments, extension indexers, labeled break and continue, and memory safety improvements.
ASP.NET Core 11 includes improvements to Blazor, Minimal APIs, SignalR, OpenAPI, validation, authentication, Web Workers, and other web development features.
Blazor AI components are experimental components designed to help developers build AI-powered user interfaces such as streaming chat, tool rendering, approval flows, and interactive AI experiences.
The Blazor AI components introduced in .NET 11 are experimental and prerelease. Developers should evaluate their maturity and API stability before using them in production.
There is no universal need to upgrade immediately. Evaluate the upgrade based on the features you need, package compatibility, project timeline, and production requirements.
.NET 11 includes many performance improvements, but actual application performance depends on the workload and architecture. Benchmark your own application rather than assuming a fixed performance improvement.
RC1 includes go-live support, but it is still a release candidate. For applications that can wait for the final release, evaluating the release candidate first and moving to the final version later may simplify production adoption.
You can start learning .NET 11 now, especially if you work with ASP.NET Core, Blazor, APIs, or C#. Learning the new features before the final release can also help you prepare for upcoming projects.
Contact us today to schedule a free, 20-minute call to learn how DotNet Expert Solutions can help you revolutionize the way your company conducts business.
About us
Comments 0