Weekly .NET Roundup: Ubuntu 26.04 Baselines and .NET 11 Previews

by TechHub

This week in .NET was split between “ship-ready platform updates” and “what's taking shape next.” Ubuntu 26.04 landed with first-class .NET 10 support out of the box, while the .NET 11 wave continued to fill in long-requested language and tooling gaps (from discriminated unions to more practical scripting). On the app side, the teams kept pushing on real developer pain points: smoother Blazor list virtualization, clearer API docs when versioning is involved, and faster inner loops across containers and MAUI. That split mirrors last week's pattern: alongside “you can try this now” items (like the Fabric ADO.NET preview driver and early .NET 11 Blazor validation direction), we are seeing more places where the platform is either ready to standardize (Linux baselines, container tags) or clearly signaling where core workflows are headed next (Blazor UX primitives, Aspire wiring, language features).

.NET 10 on Ubuntu 26.04 (and cleaner Linux + container setups)

Ubuntu 26.04 now treats .NET as a day-one citizen, with .NET 10 available immediately through apt-based installation, which simplifies provisioning for developers and reduces friction for production images built on the new LTS. The update also ties directly into container workflows: new resolute Docker image tags align with the Ubuntu 26.04 base, making it easier to standardize on a single distro version across dev, CI, and production. If you have apps pinned to older runtimes, the guidance calls out the dotnet-backports PPA as the supported path for installing .NET 8 and .NET 9 on 26.04 without fighting the default package feed. The details matter for runtime behavior too. The post highlights Linux-specific considerations like cgroup v2 (relevant for container resource limits and how the runtime sizes thread pools and GC behavior) and calls out Native AOT as part of the broader story of making .NET deployments leaner and more predictable on Linux. Put together, Ubuntu 26.04 + .NET 10 is less about a single feature and more about having a well-lit path for “install, build, containerize, run” on an LTS baseline that many teams will standardize on for the next few years. It is also a useful backdrop for last week's pipeline-oriented heads-up around PowerShell packaging changes (MSI to MSIX): between OS baselines, container images, and tooling distribution, small platform shifts tend to show up first in build agents and provisioning scripts, so this kind of “here is the supported path” guidance matters.

Blazor: more flexible virtualization and early Aspire integration

Blazor's UI performance story kept moving forward with a preview of upcoming .NET 11 improvements to the Virtualize component. The big practical change is support for variable-height items, which removes one of the most common sharp edges when trying to virtualize real-world lists (chat threads, feeds, cards, and anything where templates don't render at a consistent height). Alongside that, new APIs for controlling scroll position aim to make virtualization feel less “hands off” and more like a component you can reliably integrate into rich UX patterns (restoring scroll on navigation, jumping to items, and building “infinite list” behaviors without hacks). Coming right after last week's .NET 11 validation previews, this is another example of the team focusing on the parts of Blazor that routinely force custom plumbing (forms and lists) and moving those pain points into the framework's default toolkit. In parallel, the team showed in-progress Blazor integration work with .NET Aspire. The direction here is about making Blazor apps (both WebAssembly and Server) fit more naturally into Aspire's model for configuration flow, service discovery, diagnostics, and scaling. The “Blazor gateway” concept hints at a more opinionated way to front Blazor applications in distributed setups, while deeper hooks into Aspire would mean fewer one-off scripts and less bespoke glue for wiring services together, observing them, and scaling them consistently across environments.

.NET 11 previews: C# discriminated unions and more complete scripting

C# 15's discriminated unions were the headline language feature discussed this month, and the coverage this week focused on what actually shipped (merged for .NET 11 preview) and what to be careful about before betting designs on it. The promise is familiar if you've used F# or languages with first-class sum types: express domain states explicitly, push invalid states out of your model, and let the compiler help you handle every case. The caveat is that preview implementations often come with constraints that affect ergonomics, codegen, and interop patterns, so the advice here is to treat the feature as “learn it and experiment” rather than “rewrite core models today.” On the scripting side, .NET 11 Preview 3 filled a long-standing gap by adding file references so scripts can be structured across multiple files. That moves scripting closer to something you can maintain over time: shared helpers, reusable modules, and scripts that do not collapse into a single growing .csx file. For teams using scripts for build glue, migrations, or one-off automation, this is the difference between “handy demo” and “tool you can keep in a repo.” It also lines up with last week's theme of making .NET fit existing, familiar workflows (like exposing Fabric Spark through ADO.NET patterns): both changes reduce the “special case” tooling teams have to maintain by letting them use more standard structures and conventions.

Visual Studio and VS Code workflows: better navigation and repeatable dev environments

Visual Studio got a bookmarking rethink with Bookmark Studio, an experimental extension that turns bookmarks into something you can actually manage at scale. Instead of a flat, fragile set of markers, it adds slot-based keyboard navigation, a Bookmark Manager tool window, optional organization, and export options (text/Markdown/CSV) so bookmarks can leave the IDE when you need to share context or track hotspots. A key quality-of-life detail is improved tracking as code changes, which matters because bookmarks that drift or disappear after refactors tend to get abandoned. After last week's Visual Studio “floating windows” ergonomics tip, this continues the theme of shaving down everyday IDE friction, especially for developers working across multiple files and screens where navigation overhead adds up. On the VS Code side, a practical Dev Containers walkthrough focused on a setup many teams actually want: a .NET 8 Web API with PostgreSQL using Docker Compose, ready to run inside a containerized dev environment. The guide leans into the reality that beginners hit: Docker Desktop vs Docker Engine differences, WSL2 integration quirks, and the kinds of “it should work but doesn't” issues that slow teams down when onboarding. The value here is less about the happy path and more about having a troubleshooting checklist that makes Dev Containers viable as a default workflow instead of an occasional experiment. Paired with this week's Ubuntu 26.04 + .NET 10 baseline story, it reinforces a consistent thread: standardizing environments (Linux versions, container tags, devcontainer configs) is increasingly the practical path to fewer “works on my machine” surprises.

ASP.NET Core APIs: aligning versioning with OpenAPI output

API versioning and OpenAPI often collide in subtle ways: your routing and behavior are version-aware, but your generated OpenAPI documents can end up duplicated, inconsistent, or require a lot of manual configuration to keep tidy. This week's ASP.NET Community Standup dug into how ASP.NET API Versioning fits with the newer ASP.NET Core OpenAPI packages in .NET 10, with an emphasis on generating aligned OpenAPI documents for both Minimal APIs and controllers without repeating configuration in multiple places. The practical takeaway is that the ecosystem is converging on a cleaner approach: treat versioning as a first-class input into document generation so each version gets the right surface area and metadata, while keeping the setup maintainable as the number of endpoints grows. For teams publishing public APIs (or even internal APIs consumed by multiple services), this is the kind of plumbing work that reduces churn when you add a v2, keep v1 alive, and still want accurate client generation and interactive docs.

Other .NET News

Rick Strahl shared a deeper look at using Westwind.Scripting's ScriptParser in a real production workflow (Documentation Monster), covering practical templating concerns like layout/content composition, base URL fixups for preview vs published output, and error handling that distinguishes compilation failures from runtime failures. It is a nice real-world complement to the “.NET scripting is finally complete” thread this week: as the core scripting story gets more maintainable (multi-file structure), the community examples keep showing what “scripts you can keep in a repo” actually look like in production.