ASP.NET Core Roadmap for .NET 11 discussion

[danroth27]

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

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

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