Replies: 36 comments 57 replies
-
|
Blazor Improve:
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to see some progress around Observability. Native instrumentation support: Remove some log scopes that no longer make sense with OpenTelemetry and span attributes: |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Multithreading for Blazor WASM sounds cool, but an easy way to call web-workers, coded with .NET, would also be really nice. |
Beta Was this translation helpful? Give feedback.
-
|
Daniel Roth encourage the community to comment why they would like certain features, so just to elaborate. The Blazor WASM system I am working on generates 3D models dynamically. That requires some algorithms that blocks the UI thread and causes it to freeze. Currently we move work to the server, but web workers would really great for that scenario. I really don't want to re-write the algorithms in JavaScript, so a .NET Web Worker would be preferable. Several people have experimented with this: It may work, but has a tendency to break and seems hard to build and debug. For example fingerprinting of the static files requires an importmap, which is not supported when loading a webworker. (I think...) I'm looking for a "first class citizen" that not just happens to work with the right settings. Preferably the worker projects would be in the same solution as the Blazor project and be debuggable when running the Blazor project. Also included in the build process and bundled with the rest of the Blazor WASM project. |
Beta Was this translation helpful? Give feedback.
-
|
FYI: As far as I understand, there will be official blazor worker template: #64944 |
Beta Was this translation helpful? Give feedback.
-
|
@ScarletKuro that sound very promising! |
Beta Was this translation helpful? Give feedback.
-
|
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 blockerMany real Blazor apps rely on:
With AOT + trimming enabled, applications often build successfully but fail at runtime with errors such as:
Today, developers must rely on:
This approach is difficult to maintain and discourages using AOT in production. Suggested improvements:
System.Text.Json is not AOT-friendly by default
In medium to large applications:
Common issues only appear at runtime even though the build succeeds. Suggested improvements:
AOT + trimming should fail at build timeCurrently:
This is risky for production systems. Suggested improvements:
Trimming documentation and third-party librariesDocumentation 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:
Suggested improvements:
Trimming guidance is unclearCurrent guidance often suggests:
This leads to trial-and-error rather than confidence. Suggested improvements:
SummaryBlazor WebAssembly AOT is extremely promising, but today:
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks again, Dan! I’ve opened an issue with this feedback so it can be triaged properly: link to issue |
Beta Was this translation helpful? Give feedback.
-
|
Hi, MudBlazor maintainer here, you mentioned MudBlazor.
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). |
Beta Was this translation helpful? Give feedback.
-
no i didn’t mean specifically MudBlazor , when you set
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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
My top 3, looking for upvotes if applicable:
|
Beta Was this translation helpful? Give feedback.
-
|
My top 3 niche requests as a MudBlazor dev |
Beta Was this translation helpful? Give feedback.
-
|
Would be nice if the async validation could be considered as copilot candidate, see #7680 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
What are you building with webtransport? |
Beta Was this translation helpful? Give feedback.
-
|
A media player that supports latency under one second. |
Beta Was this translation helpful? Give feedback.
-
|
Is this an ASP.NET Core roadmap or just a Blazor roadmap? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @shawnwildermuth. This roadmap discussion is for all of ASP.NET Core, including Kestel, middleware, Minimal APIs, Blazor, SignalR, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Just making sure, I only saw Blazor improvements. |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone! 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. |
Beta Was this translation helpful? Give feedback.
-
|
Rate Limiting Improve: Hopefully, .NET Core 11 will improve Rate Limiting Middleware. Thank you very much. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
#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 |
Beta Was this translation helpful? Give feedback.
-
OpenAPI improvements and OpenAPI 3.2Areas around OpenAPI 3.2 which haven't got an issue yet.
Improvements |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
And please, please, please, also include #58332 (OpenApi custom polymorphic type names) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Trimming and AOT support for Blazor Server. |
Beta Was this translation helpful? Give feedback.
-
|
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. ) |
Beta Was this translation helpful? Give feedback.
-
Making
|
Beta Was this translation helpful? Give feedback.
-
This isn’t directly related to Since even if live switching between render modes is implemented, the current SSR behavior may still ruin the user experience when transitioning to an interactive mode. |
Beta Was this translation helpful? Give feedback.
-
|
@ScarletKuro I agree with you, but I also want to say that |
Beta Was this translation helpful? Give feedback.
-
|
Please bring back the Blazor WASM Hosted Template #55307. |
Beta Was this translation helpful? Give feedback.
-
@ScarletKuro What do you see users trip over most frequently when dealing with auth? |
Beta Was this translation helpful? Give feedback.
-
Honestly, it’s hard to know where to begin because the problems users hit with auth in Blazor Web Apps all stem from the same root issue: the documentation for Individual Accounts is too shallow and doesn’t explain the architectural constraints behind it.
Something as simple as showing the actual request flow would help a lot: The documentation should also reference the underlying fundamentals, like pointing to static versus interactive routing etc Right now, people constantly ask why MudBlazor (or any component library) "doesn’t work" on Identity pages. Another issue is that beginners often choose Individual Accounts since it’s the only authentication option the template provides, without understanding what it actually means. They don’t realize that with Individual Accounts, they are running their own identity provider. Many of these users would be better served by OIDC, OAuth2, Windows Auth, etc that don’t require static SSR at all. A dedicated, in‑depth document explaining the architecture, limitations, and intended use cases of Individual Accounts would prevent a huge amount of confusion, and would save community from having to re-explain the same things over and over. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @ScarletKuro! This is helpful. Improving our authentication docs is something we hope to make progress on this quarter. Please note that we have an Identity UI implementation for Blazor (.razor), not just for Razor Pages (.cshtml). But the Blazor Identity UI does require using static server-side rendering just like you said. It sounds like we need more documentation explaining why that is and what limitations it imposes around interactivity. |
Beta Was this translation helpful? Give feedback.
-
Yes, sorry for the confusion. I know they are still Blazor I’ve also seen Blazor folks use the same shorthand:
|
Beta Was this translation helpful? Give feedback.
-
|
@danroth27 As part of that doc effort, could you please breath some life into dotnet/AspNetCore.Docs#20222 ? There is something of a crisis going on here, as Entra is now returning tokens so long that they exceed the Azure App Service query length limit (which is not trivial to increase), thereby preventing people who use MS accounts from logging into services hosted on Azure and using There are two modern alternatives to using I do think this is mostly a doc issue rather than a code issue, although I have struggled to work out what the correct migration should be without it being documented. |
Beta Was this translation helpful? Give feedback.
-
|
Hybrid Execution Directives for Blazor Code Today, an entire Blazor component must be committed to either: This "all-or-nothing" model can sometimes lead to architectural overhead. Developers might create separate components (e.g., MyComponent.razor and MyComponentServer.razor) or use complex JavaScript interop just to run a small piece of logic in a different environment. Some times we have code that is safe to run on client, however introducing a separate component for that is too much. Proposed Feature:
|
Beta Was this translation helpful? Give feedback.
-
|
.NET 9 added the ability to detect render mode via RendererInfo which helps in Auto render mode. |
Beta Was this translation helpful? Give feedback.
-
|
This is an insane request. Components are easy to create, provide separation, are (reasonably) atomic and can be tested reliably. Adding this sort of complexity leads to security issues and spaghetti code. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to see improvements to input validation for derived types deserialized from polymorphic JSON: #54070 |
Beta Was this translation helpful? Give feedback.
-
|
implement autodiscoverability of Minimal APIs endpoints using source generators. |
Beta Was this translation helpful? Give feedback.
-
|
@ndavidb Is there an issue describing the sort of autodiscovery mechanism that you want that you can point us to? |
Beta Was this translation helpful? Give feedback.
-
|
I would like to be able to have better support for It would be great if the |
Beta Was this translation helpful? Give feedback.
-
|
In general I would like to see more js event support. Today I have to use js interop to access events like |
Beta Was this translation helpful? Give feedback.
-
|
Another thing I would like to see is built in support for local LDAP authentification. In my opinion the main benefit for Blazor Server is to develop a local intranet application inside businesses. Many businesses in Europe are still hosting their own local Active Directory and having built in support in the templates for this scenario would really help many small businesses here. |
Beta Was this translation helpful? Give feedback.
-
|
@danroth27 where can I contact you? I was asking today in the Blazor Community Standup about issues regarding the razor editor. I'm happily accepting your offer to investigate this. I have a pretty reliable way to showcase one major problem here. Sadly I cannot report it using Send Feedback because this feature isn't working for me since a couple of months now. |
Beta Was this translation helpful? Give feedback.
-
|
@MarvinKlein1508 Thanks for reaching out about this! I'm happy to connect on your preferred social platform. Hopefully we can get your Razor editor issue sorted in short order. |
Beta Was this translation helpful? Give feedback.
-
|
Question : I recall a demonstration by Scott Hunter about a year ago where WinForm desktop application, was shown running in the browser via WebAssembly. if we have a good enough .net runtime for web assembly, it will give us ability to bring our desktop apps experience to web. Do you consider developing something in that direction? If so ,would such a capability be an extension of the current Blazor WebAssembly stack, or a different technology?" |
Beta Was this translation helpful? Give feedback.
-
WASM is moving from MonoCRL to CoreCRL dotnet/runtime#121511 and it will certainly open more doors for community to experiment in this direction. |
Beta Was this translation helpful? Give feedback.
-
|
Please enhance minimal API endpoints to support dual transports (REST + gRPC) on the same endpoint. 
Something like this : // Single endpoint definition supporting both protocols
// Option A: Fluent API with automatic protobuf mapping
app.MapDual<ListProductsRequest, ListProductsResponse>()
.ToRest(HttpMethod.Get, "/api/v1/products")
.ToGrpc("ProductService", "ListProducts")
.WithHandler(async (ListProductsRequest req, ListProductsHandler handler, CancellationToken ct)
=> await handler.ExecuteAsync(req, ct))
.WithName("ListProducts")
.WithTags("Products")
.RequireAuthorization();
// Option B: Minimal lambda syntax
app.MapDual("/api/v1/products", async (
[AsParameters] ListProductsRequest request,
ListProductsHandler handler,
CancellationToken ct) => await handler.ExecuteAsync(request, ct))
.WithGrpc("ProductService", "ListProducts")
.WithName("ListProducts");
With OpenAPI docs that reflects all:
{
"openapi": "3.0.0",
"info": {
"title": "My API",
"version": "v1"
},
"x-protocols": [
{ "name": "REST", "contentType": "application/json" },
{ "name": "gRPC", "contentType": "application/grpc" },
{ "name": "gRPC-Web", "contentType": "application/grpc-web" }
],
"x-grpc-reflection": {
"enabled": true,
"endpoint": "/grpc.reflection.v1alpha.ServerReflection"
},
"x-grpc-services": [
{ "name": "ProductService", "package": "products.v1" },
{ "name": "OrderService", "package": "orders.v1" }
],
"paths": {
"/api/v1/products": {
"get": {
"operationId": "ListProducts",
"tags": ["Products"],
"summary": "List all products with pagination",
"x-grpc": {
"service": "ProductService",
"method": "ListProducts",
"streaming": "unary",
"package": "products.v1"
},
"description": "...\n\n**gRPC Alternative:**\n- Package: `products.v1`\n- Service: `ProductService`\n- Method: `ListProducts`"
}
},
"/api/v1/orders/{orderId}/updates": {
"get": {
"operationId": "StreamOrderUpdates",
"x-grpc": {
"service": "OrderService",
"method": "StreamOrderUpdates",
"streaming": "serverStreaming",
"package": "orders.v1"
}
}
}
}
} |
Beta Was this translation helpful? Give feedback.
-
Proposal: Server Actions for Blazor WebAssemblyDisclaimerI wrote this with the help of an LLM. TL;DRAdd “Server Actions” for Blazor WebAssembly: annotate a component's method to run server-side and have the framework generate the HTTP plumbing (endpoint + proxy), enabling small server “isles” without switching to websocket circuits AND without writing the usual endpoint/DTO/HttpClient boilerplate for every server interaction. ProblemBlazor currently pushes developers into one of two extremes:
GoalLet WASM components run small, explicit pieces of server-side logic without:
In short: server interactivity as needed, still over HTTP request/response. Non-GoalsThis IS NOT about replacing This IS NOT a replacement for public APIs/controllers/minimal APIs. The focus is on simple, narrowly-scoped server calls from WASM components Proposed featureIntroduce Server Actions for Blazor WebAssembly:
Action bodies must never be included in the WASM output, the browser only gets the proxy/stubs. Generated endpoints must integrate with ASP.NET Core’s existing security/auth and DI features. Why?This fills the gap between:
Server Actions would let developers keep the WASM model for UI while sprinkling in narrowly-scoped server execution when needed—cleanly, securely, and with minimal boilerplate. |
Beta Was this translation helpful? Give feedback.
-
|
Take a look at the EasyApi project |
Beta Was this translation helpful? Give feedback.
-
Thank you for the suggestion. I'm aware of the project, and find it inspiring, certainly a step in the right direction (in the context of what I proposed) although it does not really solve any of the pain points I'm trying to address with my proposal (i.e. you still need 3 different projects and a lot of boilerplate to do the plumbing) |
Beta Was this translation helpful? Give feedback.
-
|
I think that would make the WebApp even more complicated than it already is. It would just add yet another concept on top of the existing rendering modes. I think they should continue with the WASI runtime and bring it to production: |
Beta Was this translation helpful? Give feedback.
-
I feel what you say, the learning curve is already steep. I still feel that it would be a great addition to the framework overall.
I was not aware of this experiment, it sounds interesting. I will look more into that. |
Beta Was this translation helpful? Give feedback.
-
|
Steve is a legend, great visionary. Shame that his attention is more AI focused recently, but that's the industry trend nowadays. WASI as described in Extending WebAssembly to the Cloud with .NET would open up some great possibilities, please upvote dotnet/runtime#96419 if that's something you would like to see. |
Beta Was this translation helpful? Give feedback.
-
|
Would like to get feedback from other Blazor devs to see if a proposal to allow component makers to pull the display name attribute from a model (with code in |
Beta Was this translation helpful? Give feedback.
-
|
A major challenge and friction point I’ve been running into over the past few months is source‑generator chaining. The current .NET ecosystem simply doesn’t support this, and with AI making source‑code generation dramatically easier, the lack of proper chaining has become a real bottleneck in my projects. Getting it to work today requires far too many workarounds. Projects end up referencing each other in awkward ways, creating unnecessary complexity. Building large, nested source generators becomes messy and fragile. Improving this would make a huge difference, especially as AOT continues to deliver significant benefits on servers where reduced memory usage and smaller footprints matter a lot. |
Beta Was this translation helpful? Give feedback.
-
|
I also face this issue in several places:
Personally i would be happy with "less optimal" solutions, because this is such a show-stopper. Things like:
|
Beta Was this translation helpful? Give feedback.
-
|
I've opened a proposal to add an opt-in renderer-level The default behavior would remain unchanged and conservative. This would simply enable advanced scenarios (e.g. value objects/records) to opt-in to equality-based comparison when appropriate. Full proposal here: #65135 Feedback welcome on scope, API shape, and perf considerations. |
Beta Was this translation helpful? Give feedback.
-
|
Hey folks, In community I noticed focus both from
@foxminchan use https://github.com/asyncapi/saunter and https://github.com/event-catalog/eventcatalog |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions