Weekly .NET Roundup: .NET 11 RC2, Servicing, and Tooling

by TechHub

Welcome to this week's .NET roundup, where the focus is shipping-ready validation and smoother day-to-day workflows. .NET 11 RC2 arrives with go-live support and refreshed tooling guidance for Visual Studio 2026 Insiders and VS Code, while October 2026 servicing updates land across .NET 10, 9, 8, and supported .NET Framework versions. On the productivity side, dotnetup targets side-by-side SDK management, Visual Studio adds a fail-fast build option, and VS Code continues iterating on Copilot chat and agent UI for multi-repo work. We also cover practical engineering guidance (Durable Task, Minimal API serialization trade-offs, MSBuild hygiene), plus C# 15 features, SQL tooling updates, and new Blazor component options.

This Week's Overview

.NET 11 RC2 lands with go-live support and updated tooling

After last week's RC1 drop (and the early look at experimental Blazor AI components), .NET 11 Release Candidate 2 is out, and it comes with a go-live support license so teams can start validating production-like deployments while the release trains toward GA. Tooling support is called out explicitly this week: Visual Studio 2026 Insiders and VS Code (via the C# Dev Kit) are positioned as the primary IDE paths for trying RC2 features across the stack.

RC2 links out to detailed component release notes across the runtime, SDK, MSBuild, NuGet, F#, ASP.NET Core, .NET MAUI, and Windows Forms, which is useful if you need to check breaking changes or feature flags by area. If you are testing Native AOT, trimming, or newer HTTP behaviors (like HTTP/2 work), RC2 is the point where you want CI and staging coverage to look as close to reality as possible.

Staying current: October 2026 servicing updates for .NET and .NET Framework

Microsoft shipped the October 2026 servicing releases, including .NET 10.0.13, .NET 9.0.21, and .NET 8.0.32, plus updates for supported .NET Framework versions. The post serves as a navigation hub to CVE lists, release notes, installers, container images, Linux install guidance, and known issues, so you can quickly confirm what changed in your supported runtime line.

For teams managing production fleets, the practical work is verifying container base image tags, rolling forward runtime patch versions in deployment pipelines, and checking known issues before broad rollout. If you maintain apps that target both .NET and .NET Framework, this is also a good moment to align patch cadence and make sure security updates flow through the older footprint as well.

Tooling and workflow updates across IDEs and the .NET toolchain

A lot of this week’s .NET-facing news is about reducing friction in day-to-day work: installing the right SDK, cutting down wasted build time, and getting better AI and editor experiences. The common theme is making it easier to keep multiple projects and versions moving at once without fighting your environment.

dotnetup (preview): user-local .NET SDK and runtime management

dotnetup entered public preview as a toolchain manager designed for installing and updating side-by-side .NET SDKs and runtimes on macOS and Linux, including preview and daily builds. Because it is user-local, it fits well for developers who cannot (or prefer not to) modify system-wide SDK installs, and it is aimed at the “multiple SDKs per machine” reality of modern .NET work.

The post highlights workflows that matter in practice: updating SDK bands, pinning versions with global.json, and using the tool in CI-friendly ways so build agents can reliably acquire the expected SDK. If you test RCs or nightly builds, dotnetup is positioned as a cleaner path than manual installs and ad-hoc scripts.

Visual Studio 2026 (18.11): stop building after the first failure

Following last week's Visual Studio push toward more agent-driven workflows and “act from where you are” fixes (like addressing NuGet Audit warnings in the Error List), Visual Studio 2026 version 18.11 adds an opt-in setting to stop a solution build after the first project failure. That targets a common pain point in larger solutions where one broken project still leaves you waiting as queued projects continue to build.

If your inner loop depends on fast feedback, this setting can reduce dead time and help you focus on the first actionable failure instead of scrolling through secondary errors. Look for it under build behavior options (Build and Run), then evaluate how it interacts with your team’s expectations for “build everything to see all breakages” versus “fail fast and iterate.”

VS Code 1.142 and GitHub Copilot: chat, agents UI, and model picker changes

Building on last week's VS Code 1.140 emphasis on multi-folder sessions and session composer controls for agent-heavy, multi-repo .NET work, VS Code 1.142 continues to reshape the Copilot-first workflow with new “canvases,” chat improvements that work across folders and Git worktrees, and more layout control for the Agents panel. The GitHub Copilot model picker is redesigned as well, which matters if your team routinely switches models for different tasks (for example, quick edits versus deeper refactors).

For .NET developers living in VS Code, the practical takeaway is that multi-repo and worktree-heavy workflows (common in microservices and shared libraries) should feel less awkward when using chat and agent features. If you maintain standardized dev containers or onboarding docs, it may be worth updating screenshots and instructions as the Copilot UI continues to move.

SQL developer tooling: modernization workflows meet Copilot and VS Code

Microsoft used SQL Modernization Day to connect several threads that matter to .NET teams who build against SQL Server today but have Azure SQL on the roadmap. Updates span the VS Code MSSQL extension, schema-aware GitHub Copilot agent mode, and “Microsoft SQL skills” (preview) intended to assess and help migrate SQL Server workloads to Azure SQL, with additional notes on driver updates and SQL projects workflows.

The workflow angle is the key part: developers can stay inside VS Code while iterating on database work, then lean on Copilot that understands schema context, and finally use assessment and migration capabilities to plan the move to Azure SQL with fewer blind spots. The mention of SQL projects (Microsoft.Build.Sql) is a signal that “database-as-code” practices are still getting investment, which helps teams version schema changes alongside application code and integrate them into build pipelines.

Azure AI Foundry: GPT-6 GA and new orchestration and routing capabilities

Picking up on last week's .NET-side “agent stack” through-line (Foundry + MAF + MCP showing up together in samples), Microsoft Foundry’s September 2026 roundup is relevant to .NET teams building AI-assisted features because it moves core building blocks into GA and previews several control-plane features. The GPT-6 family is now GA, and both Routines and Tool Search are GA, which points toward more standardized patterns for tool-using agents (define repeatable routines, then find and invoke tools more reliably).

Foundry Insights is in public preview, giving teams more visibility into model usage and behavior, while Model Router is in preview with controls for routing decisions across models. The roundup also calls out updates across Foundry Local, Speech/Content Understanding, SDKs, and azd extensions, which is where day-to-day developer experience improvements tend to show up.

Blazor: free Ignite UI component library reaches stable release

After last week's Blazor momentum around “agentic UI” building blocks, Infragistics and the Blazor Community Standup team highlighted the stable release of the free, open-source Ignite UI component library for Blazor. For teams building line-of-business UI with Blazor, more mature open-source component options can reduce time spent on common UI patterns and help standardize design across apps.

The standup focuses on what the library includes and how to use the components in Blazor projects, which is useful when you need to quickly assess whether the component set covers your needs (tables, inputs, layouts) before committing. If you already maintain internal component wrappers, this is the kind of release worth evaluating for consistency, accessibility, and long-term maintenance posture.

Engineering patterns and performance notes for modern .NET apps

Several posts this week focus less on product announcements and more on the “how should we build this” questions: build configuration hygiene, serializer trade-offs in Minimal APIs, and durable orchestration boundaries. Together, they map to the kinds of decisions that quietly determine whether a .NET codebase stays maintainable at scale.

Durable Task: when durable waits and replay are worth it (and what you still own)

A deep dive into Durable Task and Durable Task Scheduler frames adoption around real production scenarios: durable waits, replay semantics, and recovery boundaries. The guidance is explicit that durable orchestration does not remove the need for application-owned state and reconciliation, so you still need patterns like outbox messaging, careful idempotency, and explicit recovery logic.

The post also highlights concepts like ContinueAsNew, fencing tokens, and Durable Entities, which can help avoid runaway history growth and concurrency hazards in long-running workflows. If you are building agent-like systems (the post mentions Microsoft Agent Framework) or business process automation with retries and external dependencies, this is a good checklist for deciding what belongs in the orchestrator versus your domain model.

Minimal APIs: swapping System.Text.Json for REDox may not move throughput

A practical comparison shows how to swap serialization in ASP.NET Core Minimal APIs by implementing a custom IResult, using REDox instead of System.Text.Json. Benchmarks show modest serializer wins (especially for deserialization), but the sample did not show measurable HTTP throughput improvement for the tested payload.

The useful takeaway is methodological: measure end-to-end behavior (serialization cost and HTTP throughput) before investing in serializer swaps, and validate against representative payload sizes and allocation patterns. Even when microbenchmarks look better, your bottleneck may be elsewhere (network, middleware, database latency), so the change may not pay for its complexity.

MSBuild hygiene: Directory.Build.props for shared defaults across repos

A guide on Directory.Build.props walks through how to share MSBuild defaults across projects, including how nesting affects import behavior. It also clarifies when to use Directory.Build.targets (for late-bound build logic) and Directory.Packages.props (for centralized package versions via NuGet Central Package Management).

If you are maintaining multi-project solutions (or monorepos), this is one of the simplest ways to standardize analyzers, nullable settings, LangVersion, and build properties without copy-pasting across csproj files. It also improves consistency in CI, because your build configuration lives in one place and evolves under source control.

Language evolution watch: C# 15 collection expressions and union types in practice

Two C# 15-focused posts explore “nice to have” syntax changes that can turn into meaningful API design improvements once they land in everyday code. The theme is making expressive code easier to write without sacrificing correctness, especially around constructors and state modeling.

Collection expression arguments: fixing comparer/capacity ergonomics

C# 15 collection expression arguments introduce a with(...) element that lets you pass constructor arguments (like StringComparer.OrdinalIgnoreCase or a capacity) while keeping the [ ... ] collection expression syntax. That helps in real code where HashSet<T> and dictionaries often need explicit comparer choices, but developers also want concise initialization.

This addresses a common footgun where a collection looks correct but behaves incorrectly due to default comparer choices (case sensitivity is the classic example). If your codebase adopts collection expressions broadly, with(...) gives you a way to keep readability while still being precise about semantics.

Union types: modeling workflows and serializing state with discriminators

C# 15 union types are presented as a practical way to model workflows with a single Next method and exhaustive results, leaning on exhaustive switch expressions to force handling of all states. The follow-up concern (persistence) is addressed by showing how to serialize and rehydrate union state with System.Text.Json using an explicit discriminator and custom converter logic.

For teams building state machines (order processing, onboarding flows, background job pipelines), union types can reduce boilerplate compared to class hierarchies while improving compile-time safety. The serialization guidance matters because workflow state often needs to live in a database or message payload, and “nice” type modeling is only useful if it can survive persistence boundaries.

Other .NET News

Building on last week's theme that AI help is becoming more operational (generate, review, approve, then ship), AI-assisted development workflows keep shifting from “generate code” to “generate, then review and secure,” with VSLive! San Diego discussions emphasizing validation and hands-on learning for experienced Visual Studio developers adopting Copilot. In parallel, Aspire 13.6 updates were highlighted alongside Azure VM lifecycle guidance changes and SQL Server running on Azure Local, reflecting continued investment in distributed app development and hybrid deployment patterns.

A lightweight VS Code short also reminded users that editor customization (themes) is still a quick morale and focus win, even in a week dominated by tooling and platform updates.