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

[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.

[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.