Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article highlights the most significant changes in ASP.NET Core in .NET 11 with links to relevant documentation.
This article will be updated as new preview releases are made available.
Blazor
This section describes new features for Blazor.
New DisplayName component and support for [Display] and [DisplayName] attributes
The DisplayName component can be used to display property names from metadata attributes:
[Required, DisplayName("Production Date")]
public DateTime ProductionDate { get; set; }
The [Display] attribute on the model class property is supported:
[Required, Display(Name = "Production Date")]
public DateTime ProductionDate { get; set; }
Of the two approaches, the [Display] attribute is recommended, which makes additional properties available. The [Display] attribute also enables assigning a resource type for localization. When both attributes are present, [Display] takes precedence over [DisplayName]. If neither attribute is present, the component falls back to the property name.
Use the DisplayName component in labels or table headers:
<label>
<DisplayName For="@(() => Model!.ProductionDate)" />
<InputDate @bind-Value="Model!.ProductionDate" />
</label>
Blazor Web script startup options format now supported for Blazor Server and Blazor WebAssembly scripts
The Blazor Web App script (blazor.web.js) options object passed to Blazor.start() uses the following format since the release of .NET 8:
Blazor.start({
ssr: { ... },
circuit: { ... },
webAssembly: { ... },
});
Now, Blazor Server (blazor.server.js) and Blazor WebAssembly (blazor.webassembly.js) scripts can use the same options format.
The following example shows the prior options format, which remains supported:
Blazor.start({
loadBootResource: function (...) {
...
},
});
The newly supported options format for the preceding example:
Blazor.start({
webAssembly: {
loadBootResource: function (...) {
...
},
},
});
For more information, see ASP.NET Core Blazor startup.
New BasePath component
Blazor Web Apps can use the new BasePath component (<BasePath />) to render the app's app base path (<base href>) HTML tag automatically. For more information, see ASP.NET Core Blazor app base path.
Inline JS event handler removed from the NavMenu component
The inline JS event handler that toggles the display of navigation links is no longer present in the NavMenu component of the Blazor Web App project template. Apps generated from the project template now use a collocated JS module approach to show or hide the navigation bar on the rendered page. The new approach improves Content Security Policy (CSP) compliance because it doesn't require the CSP to include an unsafe hash for the inline JS.
To migrate an existing app to .NET 11, including adopting the new JS module approach for the navigation bar toggler, see Migrate from ASP.NET Core in .NET 10 to ASP.NET Core in .NET 11.
NavigateTo and NavLink support for relative navigation
The new RelativeToCurrentUri parameter (default: false) for NavigationManager.NavigateTo and the NavLink component allows you to navigate to URIs relative to the current page path rather than the app's base URI.
Consider the following nested endpoints:
/docs/getting-started/installation/configuration
When the browser's URI is /docs/getting-started/installation and you want to navigate the user to /docs/getting-started/configuration, NavigateTo("/configuration") redirects to /configuration at the app's root instead of the relative path at /docs/getting-started/configuration. Set the RelativeToCurrentUri with NavigateTo or the NavLink component for the desired navigation:
Navigation.NavigateTo("/configuration", new NavigationOptions
{
RelativeToCurrentUri = true
});
<NavLink href="configuration" RelativeToCurrentUri="true">Configuration</NavLink>
Persist temporary data between HTTP requests during static server-side rendering (static SSR)
To persist temporary data between HTTP requests during static server-side rendering (static SSR), Blazor supports TempData. TempData is ideal for scenarios such as flash messages after form submissions, passing data during redirects (POST-Redirect-GET pattern), and one-time notifications.
TempData is available when AddRazorComponents is called in the app's Program file and is provided as a cascading value with the [CascadingParameter] attribute.
[CascadingParameter]
public ITempData? TempData { get; set; }
For more information, see ASP.NET Core Blazor server-side state management.
Blazor Hybrid
This section describes new features for Blazor Hybrid.
Release notes appear in this section as preview features become available.
SignalR
This section describes new features for SignalR.
Minimal APIs
This section describes new features for Minimal APIs.
OpenAPI
This section describes new features for OpenAPI.
Describe binary file responses
ASP.NET Core 11 introduces support for generating OpenAPI descriptions for operations that return binary file responses. This support maps the FileContentResult result type to an OpenAPI schema with type: string and format: binary.
Use the Produces<T> extension method with T of FileContentResult to specify the response type and content type:
app.MapPost("/filecontentresult", () =>
{
var content = "This endpoint returns a FileContentResult!"u8.ToArray();
return TypedResults.File(content);
})
.Produces<FileContentResult>(contentType: MediaTypeNames.Application.Octet);
The generated OpenAPI document describes the endpoint response as:
responses:
'200':
description: OK
content:
application/octet-stream:
schema:
$ref: '#/components/schemas/FileContentResult'
The FileContentResult is defined in components/schemas as:
components:
schemas:
FileContentResult:
type: string
format: binary
OpenAPI 3.2.0 support (Breaking Change)
Microsoft.AspNetCore.OpenApi now supports OpenAPI 3.2.0 through an updated dependency on Microsoft.OpenApi 3.3.1. This update includes breaking changes from the underlying library. For more information, see the Microsoft.OpenApi upgrade guide.
To generate an OpenAPI 3.2.0 document, specify the version when calling AddOpenApi:
builder.Services.AddOpenApi(options =>
{
options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_2;
});
Subsequent updates take advantage of new capabilities in the 3.2.0 specification, such as item schema support for streaming events.
Thank you @baywet for this contribution!
Authentication and authorization
This section describes new features for authentication and authorization.
TimeProvider support in ASP.NET Core Identity
ASP.NET Core Identity now uses TimeProvider instead of DateTime and DateTimeOffset for all time-related operations. This change makes Identity components more testable and provides better control over time in tests and specialized scenarios.
The following example shows how to use a fake TimeProvider for testing Identity features:
// In tests
var fakeTimeProvider = new FakeTimeProvider(
new DateTimeOffset(2024, 1, 1, 0, 0, 0, TimeSpan.Zero));
services.AddSingleton<TimeProvider>(fakeTimeProvider);
services.AddIdentity<IdentityUser, IdentityRole>();
// Identity will now use the fake time provider
By using TimeProvider, you can more easily write deterministic tests for time-sensitive Identity features such as token expiration, lockout durations, and security stamp validation.
Infer passkey display name from authenticator
ASP.NET Core Identity now automatically infers friendly display names for passkeys based on their AAGUID (Authenticator Attestation GUID). Built-in mappings are included for the most commonly used passkey authenticators, including Google Password Manager, iCloud Keychain, Windows Hello, 1Password, and Bitwarden.
For known authenticators, the name is automatically assigned without prompting the user. For unknown authenticators, the user is redirected to a rename page. Extend the mappings by adding entries to the PasskeyAuthenticators dictionary in the project.
Miscellaneous
This section describes miscellaneous new features in .NET 11.
IOutputCachePolicyProvider interface
ASP.NET Core in .NET 11 provides the [IOutputCachePolicyProvider](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/[IOutputCachePolicyProvider.cs](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/IOutputCachePolicyProvider.cs)` interface for implementing custom output caching policy selection logic. By using this interface, apps can determine the default base caching policy, check for the existence of named policies, and support advanced scenarios where policies must be resolved dynamically. Examples include loading policies from external configuration sources, databases, or applying tenant-specific caching rules.
The following code shows the IOutputCachePolicyProvider interface:
public interface IOutputCachePolicyProvider
{
IReadOnlyList<IOutputCachePolicy> GetBasePolicies();
ValueTask<IOutputCachePolicy?> GetPolicyAsync(string policyName);
}
Thank you @lqlive for this contribution!
Auto-trust development certificates in WSL
The development certificate setup now automatically trusts certificates in WSL (Windows Subsystem for Linux) environments. When you run dotnet dev-certs https --trust in WSL, the certificate is automatically installed and trusted in both the WSL environment and Windows, eliminating manual trust configuration.
# Automatically trusts certificates in both WSL and Windows
dotnet dev-certs https --trust
This improvement streamlines the development experience when using WSL, removing a common friction point for developers working in Linux environments on Windows.
Thank you @StickFun for this contribution!
Native OpenTelemetry tracing for ASP.NET Core
ASP.NET Core now natively adds OpenTelemetry semantic convention attributes to the HTTP server activity, aligning with the OpenTelemetry HTTP server span specification. All required attributes are included by default, matching the metadata previously only available through the OpenTelemetry.Instrumentation.AspNetCore library.
To collect the built-in tracing data, subscribe to the Microsoft.AspNetCore activity source in your OpenTelemetry configuration:
builder.Services.AddOpenTelemetry()
.WithTracing(tracing => tracing
.AddSource("Microsoft.AspNetCore")
.AddConsoleExporter());
No additional instrumentation library (such as OpenTelemetry.Instrumentation.AspNetCore) is needed. The framework now directly populates semantic convention attributes on the request activity, such as http.request.method, url.path, http.response.status_code, and server.address.
If you don't want OpenTelemetry attributes added to the activity, you can turn it off by setting the Microsoft.AspNetCore.Hosting.SuppressActivityOpenTelemetryData AppContext switch to true.
Performance improvements
Kestrel's HTTP/1.1 request parser now uses a non-throwing code path for handling malformed requests. Instead of throwing BadHttpRequestException on every parse failure, the parser returns a result struct indicating success, incomplete, or error states. In scenarios with many malformed requests — such as port scanning, malicious traffic, or misconfigured clients — this eliminates expensive exception handling overhead and improves throughput by up to 20-40%. There's no impact on valid request processing.
The HTTP logging middleware now pools its ResponseBufferingStream instances, reducing per-request allocations when response body logging or interceptors are enabled.
Breaking changes
Use the articles in Breaking changes in .NET to find breaking changes that might apply when upgrading an app to a newer version of .NET.
Collaborate with us on GitHub
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
ASP.NET Core