Blazor Community Standup | Blazor integration with Aspire
TL;DR
Microsoft is finally smoothing out Blazor + Aspire’s rough edges — Daniel Roth and Javier Calvarro Nelson said the team is targeting .NET 11-era improvements for service discovery, telemetry, debugging, and production hosting, especially for Blazor WebAssembly apps inside Aspire.
The new “Blazor gateway” is the centerpiece — it replaces the old dev-only hosting model for standalone Blazor WebAssembly with a production-capable host that serves compressed and fingerprinted assets, flows config to the client, and includes a built-in YARP proxy.
Telemetry is the big before-and-after moment — Javier demoed structured logs, traces, and metrics from a Blazor WebAssembly app appearing in the Aspire dashboard, something that doesn’t work out of the box today.
The gateway avoids the ‘reign of hell that is CORS’ — instead of handing the browser direct API URLs, Aspire can proxy calls like app/{appName}_api/{service} through the gateway so everything stays same-origin and the client doesn’t need special CORS setup.
This is not vaporware: the pattern already works on .NET 10 — Javier pointed to an open PR in the Aspire repo and said the current demo app is a .NET 10 app, with first-class templates and polish still in progress.
There was one practical announcement beyond Aspire — ASP.NET Core 2.3 on .NET Framework will reach end of support on April 7, 2027, and the team recommended planning migrations now, including using GitHub Copilot app modernization tooling.
The Breakdown
A quick but important retirement notice
Before getting into Aspire, Daniel opened with a heads-up: ASP.NET Core 2.3 on .NET Framework is officially on the clock. Microsoft will end support on April 7, 2027, which means no more security fixes or updates after that, and Daniel was pretty blunt that the gap between 2.3 and modern .NET 10 is now so large that using 2.3 as a migration stepping stone has lost a lot of its value.
Why Blazor and Aspire still feel awkward together today
Daniel framed the real problem: Aspire is great for orchestrating apps, but Blazor WebAssembly misses many of the “niceties” server apps get automatically. The pain points are concrete — no clean service discovery flow to the browser, no OpenTelemetry data in the Aspire dashboard, and confusing debugging because launching from the Aspire dashboard doesn’t set up the browser for remote WebAssembly debugging.
The bigger bet: treat Aspire as the deployment model
Javier’s pitch was that Aspire should become the mental model for building and deploying Blazor apps, not just a dev-time toy. He described it as an abstraction over Azure Container Apps, Kubernetes, Docker, and other environments, so teams can target Aspire instead of rethinking deployment details for every platform — and Daniel added that the MCP/logging integration with agents like GitHub Copilot makes the whole setup feel “almost magical.”
Enter the Blazor gateway
The main reveal was a new “gateway” component for standalone Blazor WebAssembly apps. Javier positioned it as an upgraded version of the Blazor dev server: still able to host static assets locally, but also viable for production, with compression, fingerprinting, config flow from server to client, and a built-in YARP proxy. He said the existing dev server will be retired from the default template in favor of this cleaner, more flexible gateway.
The telemetry demo that makes the case
Javier then showed the Aspire dashboard lighting up with structured logs, traces, and metrics from a Blazor WebAssembly app. You could see browser navigations, click events, HTTP requests to the weather API, and metrics arriving on the usual 60-second cadence — and Daniel called out that none of this shows up automatically today when you create a standard Blazor WebAssembly app.
Why the proxy matters: same-origin over CORS pain
One of Javier’s most memorable lines was calling direct browser-to-API setup “this reign of hell that is CORS.” Instead of exposing raw API URLs to the client, the gateway proxies requests using a route pattern like app/{appName}_api/{service}, which keeps everything on the same origin and makes development and production feel much more consistent. He also noted this works well for mixed front ends too — Blazor alongside Angular or React.
How the config flow actually works under the hood
The server side sets up static assets, reverse proxying, and a config endpoint that emits the JSON needed for the WebAssembly app to boot. A JavaScript initializer fetches that config, writes it into emulated environment variables in the browser, and then the .NET configuration system picks it up like any other app. Daniel laughed at the weirdness of “environment variables” inside a browser, but Javier’s point was that WebAssembly emulates enough runtime concepts to make existing .NET libraries and patterns work.
Questions, shipping plans, and what’s available now
In Q&A, they clarified that the gateway can front replicated APIs and Blazor Server apps, helps with session affinity scenarios, and can be composed with existing API management layers. On timing, the polished first-class experience is aimed at the .NET 11 timeframe, but Javier stressed the demo is already running on .NET 10 and the integration is visible today in an Aspire PR — the code exists now, even if the templates and “one gesture” UX are still being finished.