ASP.NET Core Roadmap for .NET 11 discussion

[danroth27]

Discussion thread on the ASP.NET Core Roadmap for .NET 11

You can best express your support for specific GitHub issues by giving a 👍 reaction on the original post in the issue and by commenting with details about your scenarios and requirements. We try our best to prioritize work based on broad community support and feedback.

Also, check out the ASP.NET Core planning kickoff for .NET 11 for a discussion of our planning process and proposed themes.

[coder-johnz]

Blazor Improve:

1. Real multithreading: Real multithreading in Blazor WebAssembly #17730
2. Improve startup performance: Improve the load time performance of Blazor WebAssembly apps on low-end mobile devices #42284
3. Avoid completely replacing the DOM when Blazor components are re-rendered after prerendering Avoid completely replacing the DOM when Blazor components are re-rendered after prerendering #42561

[danroth27]

Thanks @coder-johnz for sharing this feedback! If you haven't already, please make sure you've given a 👍 reaction on the original post for these issues to indicate your interest. It also helps if you can comment on the issue with details about your specific scenarios and requirements.

[joegoldman2]

I would like to see some progress around Observability.

Native instrumentation support:

• Native Trace Instrumentation Support for ASP.NET Core as per OTel specification #52439

Remove some log scopes that no longer make sense with OpenTelemetry and span attributes:

• Ability to disable ConnectionId and RequestId + RequestPath scopes #31028
• Remove default logging scope from ASP.NET Core #44873

[danroth27]

Thanks @joegoldman2! Adding native trace instrumentation support for ASP.NET Core was certainly one of the things we hoped to do for .NET 10 but ended up not getting done due to resource constraints. It's on our list of things we'd love to get done for .NET 11.

[lskyum]

Multithreading for Blazor WASM sounds cool, but an easy way to call web-workers, coded with .NET, would also be really nice.
They could be coded as a standalone WASM projects (not Blazor) that implements some kind of communication channel.

[sardar97]

First of all, thank you for the continued work on Blazor WebAssembly and .NET Native AOT. Blazor WASM has reached an impressive level of performance, and AOT has huge potential for real production applications.

However, in real-world production projects, enabling AOT together with trimming is still very difficult and fragile, especially when reflection, System.Text.Json, and third-party component libraries are involved.

Below are some concrete pain points and suggestions based on real production usage.

---

Reflection remains a major blocker

Many real Blazor apps rely on:

• Generic components
• Dynamic model binding
• Reflection-based frameworks
• Third-party UI libraries (grids, forms, validators, etc.)

With AOT + trimming enabled, applications often build successfully but fail at runtime with errors such as:

• MissingMethodException
• CtorNotLocated
• Components failing to render
• JSON deserialization failures

Today, developers must rely on:

• DynamicDependency attributes
• linker.xml
• Disabling trimming for entire assemblies

This approach is difficult to maintain and discourages using AOT in production.

Suggested improvements:

• Better automatic reflection analysis for Blazor components
• Clear diagnostics explaining what was trimmed and why
• A more Blazor-aware trimming mode instead of generic aggressive trimming

---

System.Text.Json is not AOT-friendly by default

System.Text.Json relies heavily on reflection unless source generation is explicitly configured.

In medium to large applications:

• Models are shared across layers
• DTOs evolve frequently
• Maintaining JsonSerializerContext manually does not scale well

Common issues only appear at runtime even though the build succeeds.

Suggested improvements:

• A Blazor-specific default JSON source generation strategy
• Automatic serializer generation for:
  • Component parameters
  • DTOs used by HttpClient
• Better build-time diagnostics when JSON metadata is missing in AOT builds

---

AOT + trimming should fail at build time

Currently:

• CI/CD pipelines pass
• Applications fail only in the browser console after deployment

This is risky for production systems.

Suggested improvements:

• A strict AOT validation mode
• Build-time errors or warnings when required members are trimmed
• Clear guidance on what must be preserved for AOT safety

---

Trimming documentation and third-party libraries

Documentation around trimming safety needs significant improvement, especially when using third-party Blazor libraries.

Libraries such as Syncfusion and MudBlazor are widely used in production, yet:

• AOT and trimming guidance is fragmented
• Developers must search across docs, GitHub issues, and blog posts
• There is no clear, official guidance on what is safe to trim

Suggested improvements:

• Official documentation covering AOT + trimming with common third-party libraries
• Clear examples for popular libraries such as Syncfusion and MudBlazor
• Best practices for both library authors and application developers

---

Trimming guidance is unclear

Current guidance often suggests:

• “Enable trimming”
• Followed by “disable trimming for these assemblies”

This leads to trial-and-error rather than confidence.

Suggested improvements:

• Official, opinionated AOT presets (Conservative / Balanced / Aggressive)
• Clear documentation for each preset including:
  • Size impact
  • Reflection limitations
  • Required annotations

---

Summary

Blazor WebAssembly AOT is extremely promising, but today:

• Reflection remains fragile
• System.Text.Json is not AOT-friendly by default
• Failures appear at runtime instead of build time
• Trimming documentation is insufficient for production apps using third-party libraries

Improving reflection handling, JSON source generation defaults, build-time diagnostics, and trimming documentation (especially for libraries like Syncfusion and MudBlazor) would make Blazor WebAssembly AOT far more reliable and production-ready.

Thank you again for your continued work on Blazor and .NET.

• Make Blazor WebAssembly apps fully trimmable #49409

[sardar97]

Thanks again, Dan! I’ve opened an issue with this feedback so it can be triaged properly: link to issue
Looking forward to any updates on this, and thanks again for all the work on Blazor and .NET.

[ScarletKuro]

Hi, MudBlazor maintainer here, you mentioned MudBlazor.
Just to clarify, are you mainly asking for a clear, explicit statement/documentation about MudBlazor’s support for AOT + trimming?
MudBlazor does support trimming, and many people (myself included) run trimmed MudBlazor apps in production. I believe AOT should work as well, at least we’re not aware of MudBlazor-specific AOT issues at the moment (if we are talking about WebAssembly AOT).

diagnostics, and trimming documentation

Btw, I’m happy with the documentation and the trimming analyzer diagnostic overall. The Microsoft documentation is clear on the Blazor side, and when it isn’t, we usually contribute by reporting it ourselves (dotnet/AspNetCore.Docs#28630).

[sardar97]

Just to clarify, are you mainly asking for a clear, explicit statement/documentation about MudBlazor’s support for AOT + trimming?

no i didn’t mean specifically MudBlazor , when you set <TrimMode>full</TrimMode> it will break and remove almost every components , so you need to define which component to be not removed or skip trimming , for 3rd parties needs more extra configuration which is painful to find DLLs and define them with exact name , so would be nice if we had and option to not remove any component unless we define any to remove, so currently it is safe to use <TrimMode>partial</TrimMode> but it does reduce the size of the app much. #49409

Btw, I’m happy with the documentation and the trimming analyzer diagnostic overall. The Microsoft documentation is clear on the Blazor side, and when it isn’t, we usually contribute by reporting it ourselves (dotnet/AspNetCore.Docs#28630).

i accidentally found this docs which is very nice explained everything in detail where you wouldn’t find them on the website that much clear.

[jimiscott]

We have a large (ISH) Blazor Wasm project (~150 components), with Syncfusion components, components with reflection, AoT'd. No issues except for our Humanizer dependency as we enabled the localisation trimming (or whatever it's called). We thought AoT was going to be full of pitfalls, but it just worked!

[ScarletKuro]

when you set <TrimMode>full</TrimMode> it will break and remove almost every components , so you need to define which component to be not removed or skip trimming

The documentation is quite clear on this matter. Partial trimming already allows the library size to be reduced from 8MB to 100KB in case of MudBlazor (depending on what you use). So I'm not sure why you'd need any further reduction. You wouldn't want the trimmer to be too aggressive anyway, and currently it has a good balance. It seems like you're getting a bit ahead of the curve here.

[mguinness]

My top 3, looking for upvotes if applicable:

• Add Blazor support for DisplayName DisplayNameFor support in Blazor #49147
• Allow customization of IdentityApiEndpointRouteBuilderExtensions Add ASP.NET Core Identity Endpoints scaffolder Scaffolding#3169
• Fix ReadFromJsonAsync not working w/ EnableBuffering() Unified code in net9 is normal, but from .net9 to .net10, aspnet core model bind has a json error #64323

[ScarletKuro]

My top 3 niche requests as a MudBlazor dev

• Restrict parent and child component hierarchy in blazor #12302
• Async validation enhancements #7680
• [Blazor] Add more analyzers #44690

[brianmed]

I'm very grateful for the current HTTP/3 via QUIC implementation used by WebTransport. Is it technically possible to take HTTP/3 and WebTransport out of beta and support datagrams in WebTransport? If so, will there be time?

[davidfowl]

What are you building with webtransport?

[brianmed]

A media player that supports latency under one second.

[shawnwildermuth]

Is this an ASP.NET Core roadmap or just a Blazor roadmap?

[danroth27]

Hi @shawnwildermuth. This roadmap discussion is for all of ASP.NET Core, including Kestel, middleware, Minimal APIs, Blazor, SignalR, etc.

[shawnwildermuth]

Just making sure, I only saw Blazor improvements.

[jhonatanjacinto]

Hi everyone!
I know Blazor is the new kid on the block that is receiving all the spotlights but I would like to suggest some improvements for MVC and Razor Pages as well (since these technologies are still solid options to use for many of the projects that I build and maintain).

Here are some suggestions that are simple, but will make a huge difference:

Razor Pages: ability to use the directive @page to define multiple URLs for a given page (following the same behaviour that we have with MVC - with multiple [Route()] attributes - and also Blazor - that already allows that). It is a way to keep consistency across ASP.net Core flavours.

Eg.: The follwing code is allowed on Blazor but not on Razor Pages (Index.cshtml, for instance)

@page "/books"
@page "/books/page/{page:int=1}"

... Rest of the code ...

MVC: Allow @RenderBody (or something equivalent) for ViewComponents so we can easily have child elements nested in the component when using TagHelpers.

The following code is not allowed today.

<vc:upcoming-events limit="3">
    <h3>Some child content here</h3>
</vc:upcoming-events>

These are my contribution.

Thank you very much.

[lqlive]

Rate Limiting Improve:

• Epic: Rate Limiting #53426
• Rate Limiting configuration - policy validation #45684

Hopefully, .NET Core 11 will improve Rate Limiting Middleware. Thank you very much.

[Kumima]

• Support custom error messages when validation fails on minimal APIs #35501
• Blazor Server auth improvements #38111
• OAuth 2 refresh token support #8175

[PaulusParssinen]

#35501 +1.

This is one of the biggest issues which weighs on my mind whenever someone asks me whether to use Minimal APIs or not. There's no way to give proper response to public API consumer why any primitive type binding fails with RDG-based approach. You can hit this with simply accepting a basic date/time primitive as your request/route parameter resulting nothing other than empty BadRequest response for slightly malformed input causing IParsable.TryParse return false.

[desjoerd]

OpenAPI improvements and OpenAPI 3.2

• OpenAPI 3.2.0 just released #63754
• OpenAPI 3.2 Support for Server Sent Events #64379

Areas around OpenAPI 3.2 which haven't got an issue yet.

• Support of tag collections.

Improvements

• Allow adding XML documents at runtime to OpenApi living inside a Nuget Package #64439
• OpenAPI: Marking Operations, Schemas and Properties as deprecated based on the [Obsolete] attribute #63494
• SchemaReference improvements/transformers.

[sander1095]

Great thoughts, @desjoerd ! Fully agree.

To add to this, I'd love some thoughts from the .NET team about #64858 and #58723 .

The first one especially, as building OpenAPI-correct controllers has been severely hindered because of the deprecation of the OpenAPI analyzer in .NET 10. The roadmap doesn't mention controllers at all, and it would be terrible for developer productivity (to me, and lots of other devs) to not get this fixed.

@danroth27 @mikekistler I hope you can share your thoughts on that issue.

[boukenka]

My requests as Blazor dev :

• Introduce the concept of state transitions in Blazor to allow for e.g. animations #10389
• Blazor: bind-value-oninput or bind does not work with contenteditable divs #9974
• Blazor: Record Type binding and validation for EditContext/EditForm #31604
• Provide a pure code model for creating and working with Blazor components #44866

[hez2010]

Trimming and AOT support for Blazor Server.
I really hope that I can finally build a self-contained small standalone native executable file and tell my customers just to run it to get the whole server app up.
This kind of thing becomes more and more important due to AI applications, where now you can build an MCP server with ASP.NET Core, and an admin console or dashboard that configures/monitors the MCP server using Blazer Server.
It would be a huge selling point if the server itself were just a small native exe that can run directly without any additional environment setup. Containers are not suitable here as MCP servers usually operate in your physical environment directly, so they need to be small, fast, and self-contained.

[willdean]

Could we have something along the lines of #43959 or #44162?

Both of these are about letting Blazor see authorization failure information (which is already there, it's just not really plumbed through to Blazor. )

[paule96]

I couldn't find issues for my two requests quickly (but I know they exist somewhere)

Enhanced OpenTelemetry Support for Blazor WebAssembly

Current OpenTelemetry integration in Blazor WASM is limited to console output, which restricts its usefulness in production scenarios. There is no straightforward way to push telemetry data to a metrics server. Improved native support for exporting telemetry from Blazor WASM applications would significantly strengthen observability and monitoring capabilities.

Issues

• Tracing not working in Blazor WebAssembly application open-telemetry/opentelemetry-dotnet#2816

Improved Aspire Integration for Blazor WebAssembly

At present, Aspire support for Blazor WASM is minimal—projects can be started, but deeper integration is lacking. A development workaround exists via Aspire4Wasm, but deployment remains unclear. The ideal vision would be to enable seamless integration of Blazor WASM static file projects into a gateway (reverse proxy), allowing them to be managed and routed alongside other services. This would provide a consistent and production-ready deployment model.
Something like:

var frontend = builder
        .AddStandaloneBlazorWebAssemblyProject<Projects.Frontend>("frontend")
var gateway = builder.AddYarp("gateway");
// place the frontend under the route "/frontend"
gateway.AddStaticProject(frontend, "/frontend")

This then also needs the first request to be complete. Because in a perfect world, we have traces from the frontend to the backend to the database/storage.

[MichaelPeter]

WASI Support / Server Side Plugins with WASM+Web Assembly Component model

Not sure if this is part of aspnetcore since aspnetcore would host the plugin architecture but ultimatly done by .NET itsefl
I would post it in the dotnet/core repo, but there doesn't seem to be a roadmap for .NET11?

Would be interested in WASI/WASM support for 3rd party plugins that can run inside a throttled and save sandbox
on the server. Could also be done with WASM+Web Assembly Compoent Model

I would create a seperate issue but I am not sure this is part of dotnet/aspnetcore or more dotnet/core.

WebAssembly plugins have the advantage that they are much smaller than docker images or spinning up
a isolated javascript runtime on the server.

And since .NET generates different Wasm Modules and only dotnet.native and other dependencies
take most of the filesize these dependencies could be cached by a plugin engine or wasmtime.

Here is the issue tracking WASI progress
dotnet/runtime#65895

[lskyum]

Especially the "throttled and safe sandbox" would make a big difference for our plugin system. Not having to worry (as much) about security and performance issues we could allow customers to write their own plugins.

[danroth27]

What sorts of server hosted plugins are you interested in enabling?

[lskyum]

Our system uses .NET plugins for customizing some behavior. The logic can be quite complex, so it's not just a bunch of settings.
Some customers have the skills and desire to maintain the plugins themselves, but we can't really allow this, because we haven't found any way to sandbox them properly. If a WASI/WASM runtime could be isolated and limited with both CPU and memory, that could be a solution.

[IrakliLomidze]

Blazor Pages

Concept:
Introduce a new type of ASP.NET Core MVC project capable of rendering certain views as Blazor applications. This approach enables developers to leverage the benefits of both traditional MVC and modern Blazor within a single technology stack.

Motivation:
For large-scale monolithic applications, combining ASP.NET Core MVC with Blazor Server/WebAssembly provides a powerful full-stack solution. To better organize such projects, we can modularize them into distinct subdomains while retaining a single project.

Benefits:
Blazor Pages allows multiple Blazor Server apps to coexist within one project. It could serve as a new MVC application type where views can be built using either classic Razor syntax or Blazor components.

[danroth27]

We do have some support for this today. We ship a RazorComponentResult that you can use to return a Blazor component from a controller action. We also have a ComponentTagHelper that you can use to render Blazor components from MVC Views and Razor Pages. See https://learn.microsoft.com/aspnet/core/blazor/components/integration for more details. Can you clarity what additional functionality is still missing?

[PavelCibulka]

Minimal API - templating engine. There is no fast templating engine for HTML pages in dotnet. Razor and Blazor performance make them unusable. There is already ideal solution - Razor Slices. They also support AOT. Making them official part of Minimal API would be great.
https://github.com/DamianEdwards/RazorSlices

[cirrusone]

1. Defining JsonSerializerContext boilerplate creates large cumbersome classes and is a pain to maintain. Eg can this be auto generated?

using System.Collections.Generic;
using System.Text.Json.Serialization;

namespace RandomProjectName.Shared;

[JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.Unspecified, GenerationMode = JsonSourceGenerationMode.Default, WriteIndented = false)]
[JsonSerializable(typeof(JsonResponse<SampleType001>), TypeInfoPropertyName = "JsonResponseOfSampleType001")]
// 001 to 012
[JsonSerializable(typeof(JsonResponse<SampleType012>), TypeInfoPropertyName = "JsonResponseOfSampleType012")]
[JsonSerializable(typeof(List<SampleType013>), TypeInfoPropertyName = "ListOfSampleType013")]
[JsonSerializable(typeof(SampleType014))]
// 14 to 565
[JsonSerializable(typeof(SampleType565))]

public partial class RandomJsonContext : JsonSerializerContext
{
    // JsonContext to allow AOT of serialize / deserialize
}

2. Can we have more love for Consider fast-path deserialization logic in JSON source generator

3. Can trimming and AOT errors be flagged as warnings or errors rather than just failing publish?

[martincostello]

I think all these items are for dotnet/runtime, rather than dotnet/aspnetcore as they concern System.Text.Json and the native AoT compiler.

[cirrusone]

These issues are prevelant in a current Blazor project but understand there is a cross-over. Is there an equivalent net11.0 roadmap discussion for dotnet/runtime?

[martincostello]

Not that I can immediately see.

[danroth27]

It's still useful for us to hear that these specific dotnet/runtime issues are directly impacting .NET web development scenarios so we can follow up with the appropriate folks. Adding @jeffhandley to comment on these specific items.

[Trivivium]

I would like to see improvements around using a branched middleware pipeline to modularize a modular application deployed as a monolith.

For example, the built-in authorization handlers doesn't use respect the base-path, so all redirects caused by authentication middleware in the branched pipeline, it related to the root instead.

In generel, it feels like a lot of the built-in middlewares assumes it runs as part of the "root" pipeline.

Related issues:

• .NET 7 UseAuthentication and UserAuthorization ordering not respected when within UseWhen #48098
• ASP0001 warning when used inside app.MapWhen #41030
• MapMiddleware extensions are missing in new Endpoint. #14514

[mikermnv]

Making auto render mode production‑ready

First of all, thank you for the progress already made with Blazor’s render modes.
The auto mode has great potential to simplify developer experience and deliver the best possible performance for end users. To "unlock" this potential in production scenarios, it requires full automatic live switching between all supported render modes.

Achieving this would put Blazor on par with leading JavaScript frameworks in terms of performance efficiency and resource costs, ensuring that developers can confidently choose Blazor for production workloads without compromise.

Currently, we already have:

• SSR → InteractiveServer (after prerendering)
• SSR → WASM (after prerendering)

We also have StatePersistence, which allows saving state between different render modes.
However, what’s still missing is the final step:

• SSR → InteractiveServer → WASM in auto mode, so that once a user opens a page, the app can download and load WASM files while the user continues interacting through InteractiveServer, and then, when WASM is ready, it automatically switches to WASM without manually reloading the page.

Request: Please complete the implementation so that auto becomes a fully working option for production scenarios.

References:

• Blazor: Hot switching to WASM from Server Render Mode #59641
• Blazor Web App render mode interactive auto does not switch from interactive server to interactive wasm when navigating between pages #53799