Weekly .NET Roundup: Aspire GA on App Service and MAUI reaches Linux

by TechHub

This week's .NET updates focused on meeting developers where they are: keeping code-first workflows while widening where apps can run. It continues last week's two-track theme: maintain a stable production baseline (PowerShell 7.6 LTS on .NET 10, smoother VS Code Insiders tooling) while trying newer .NET 11 Preview 2 features (like MAUI Maps pin clustering). This week, that split shows up as Aspire getting a supported Azure deployment path and MAUI exploring broader targets via Avalonia's rendering stack.

.NET Aspire on Azure App Service (GA)

Aspire on Azure App Service reached GA, taking Aspire from local orchestration to a deployable, AppHost-defined topology on App Service without abandoning the Aspire model. Like last week's focus on maintaining a known-good baseline, this GA gives teams already using AppHost locally a clearer production path with fewer conceptual jumps. The core is the Aspire.Hosting.Azure.AppService NuGet package. You define your App Service environment in AppHost code alongside familiar local constructs: project references, health checks (for example, WithHttpHealthCheck("/health")), and endpoint exposure (WithExternalHttpEndpoints()). For teams standardizing on code-defined configuration, keeping the app's “shape” in AppHost reduces drift between local and hosted environments. A practical GA detail is support for Deployment Slots, mapping to typical staging/production workflows. From AppHost you can declare a slot (for example, .WithDeploymentSlot("dev")) with behavior to note: if production does not exist, deployment creates production and the staging slot with identical config; if production exists, deployment targets only the staging slot. Scaling is supported manually (via AppHost code or portal), and rule-based scaling is available through Azure Monitor Autoscale, but fully automatic scaling is not part of Aspire-on-App-Service yet. Overall, this is a bridge from local composition to managed App Service while keeping AppHost as the source of truth for dependencies and topology.

.NET MAUI + AvaloniaUI backend (preview) for Linux and WebAssembly

Last week's .NET 11 Preview 2 notes highlighted MAUI control work (like Maps pin clustering). This week's MAUI update is about platform reach: a preview AvaloniaUI “backend” for .NET MAUI adds Linux desktop and WebAssembly targets. It's based on .NET 11 preview and is expected to remain preview until .NET 11 GA (projected around November), matching the “try it, expect churn” posture implied by last week's preview coverage. The approach swaps rendering. Instead of only MAUI's native handler model, MAUI apps can render UI using Avalonia's custom-drawn control stack, either alongside or replacing MAUI controls. The trade is clear: keep the MAUI app model while gaining Avalonia's cross-platform reach (Windows, macOS, Linux, iOS, Android, WebAssembly) without rewriting into an Avalonia-first architecture. It also creates a continuation path: the same MAUI app can use new MAUI controls on mobile while experimenting with Linux/browser targets via the backend, though behavior/rendering may differ because the control stack changes. The preview has constraints teams need to plan for. Microsoft MAUI API coverage is incomplete, especially around storage/media, so workarounds or waiting may be required. Linux relies on X11/XWayland rather than Wayland, which can block modern desktops. On Windows, it does not yet support hosting Avalonia controls inside WinUI (MAUI's Windows stack), limiting hybrid composition. Engineering from this backend is also feeding into Avalonia 12 controls/APIs and efforts to reduce MAUI/Avalonia control differences. For MAUI teams that need Linux desktop or browser targets, it's a workable option if you can tolerate preview gaps and cross-platform UI churn.