Weekly .NET Roundup: .NET 11 RC1, servicing, and smarter APIs

by TechHub

This week's .NET roundup centers on shipping and hardening: .NET 11 Release Candidate 1 arrives with go-live support, and September servicing updates land across supported .NET and .NET Framework versions. On the developer experience side, C# 15 unions and closed hierarchies move from theory to practice in ASP.NET Core, with concrete guidance for JSON binding and OpenAPI anyOf contracts. We also look at cleaner Azure-to-App Service integrations using Managed Identity, new troubleshooting patterns for distributed .NET Aspire apps with Visual Studio and Copilot, local AI agent evaluation in .NET with Agent Framework and Ollama, and CodeQL updates that make ARM64 scanning workflows easier to run and maintain.

This Week's Overview

.NET 11 Release Candidate 1 lands with go-live support

Building on last week's preview-testing push around .NET 11 and C# 15, .NET 11 Release Candidate 1 (RC1) is out, and Microsoft is treating it as a production-ready milestone with go-live support. That matters if you want to start validating upgrades now (CI, containers, hosting, SDK pinning) while staying on a supported train ahead of the final release.

RC1 is also where the stack-level story comes together: runtime and libraries, the SDK toolchain (MSBuild and NuGet), language updates (including C# 15), and framework updates across ASP.NET Core, .NET MAUI, and desktop (Windows Forms). If you maintain shared libraries or templates, this is the point to test multi-targeting, trimming/AOT assumptions, analyzers, and OpenAPI/source-gen behavior against the near-final bits.

The .NET team also did a “release party” style walkthrough that highlights practical features and the thinking behind them, which can help you triage what to actually try first in your codebase.

September 2026 servicing updates for .NET and .NET Framework

Microsoft shipped the September 2026 servicing releases across supported .NET and .NET Framework lines, including .NET 10.0.12, .NET 9.0.20, and .NET 8.0.31. The post calls out fixed CVEs (via MSRC) and aggregates the practical links you need to patch quickly: release notes, downloads, container images, Linux install guidance, and known issues.

For teams running ASP.NET Core and Entity Framework Core in production, this is the kind of update you want flowing through environments on a predictable cadence. If you publish containers, the explicit container image links make it easier to rebuild and redeploy with patched base layers without guessing which tags picked up the fixes.

Modeling APIs with C# 15 unions and closed hierarchies in ASP.NET Core

Following last week's C# 15 union-types discussion in the abstract, this week shows the practical payoff in ASP.NET Core: C# 15 union types and closed class hierarchies are starting to reshape how you model “one of several shapes” data, especially when JSON is the contract. The guidance walks through how System.Text.Json handles polymorphic serialization and deserialization for these types, including what happens when payloads are ambiguous and how to resolve that with classifiers (so the binder can pick the right case deterministically).

This has real impact on Minimal APIs, MVC, SignalR, and Blazor because those stacks all rely on the same core JSON and binding behavior. It also shows how these shapes map into OpenAPI generation using anyOf, which is often the difference between “this is nice in C#” and “this is usable by client generators.”

If you expose public APIs, the key practical takeaway is to decide early whether you want discriminator-like metadata (classifiers) versus inference-based binding, and then ensure your OpenAPI and client expectations match. That decision tends to ripple into versioning strategy, backwards compatibility, and how strictly you validate incoming requests.

Azure integration and identity: Managed Connectors can trigger App Service

Azure Managed Connectors added a public preview option that lets triggers target Azure App Service directly. The flow uses Managed Identity, and App Service built-in authentication (Easy Auth) validates the Microsoft Entra ID token, which removes a lot of custom auth glue that teams commonly build for webhook-style integrations.

For .NET teams hosting ASP.NET Core apps on App Service, this is a cleaner path for event-driven integrations where you want Azure to manage credentials and token issuance. The linked end-to-end sample is practical because it shows the full developer workflow (ASP.NET Core plus infrastructure) using Bicep and the Azure Developer CLI, which is the combination many teams are standardizing on for repeatable deployments.

Dev-time profiling and agentic assistance in .NET Aspire + Visual Studio

Finding hidden latency in distributed .NET Aspire apps

Building on last week's shift toward agentic debugging and tighter reproduce-fix-validate loops, a new troubleshooting walkthrough shows a common pitfall in distributed apps: CPU sampling can look fine while end-to-end latency stays high because the time is actually spent waiting (async waits, delays, IO). The process starts by attaching Visual Studio CPU Usage to the right process, then adds targeted timing to explain what sampling cannot, and finally uses the GitHub Copilot Profiler Agent to sanity-check the interpretation.

If you are building with .NET Aspire, the practical angle is the “choose the right process, then validate hypotheses” loop. This is a useful pattern when your system has multiple services and the slow path jumps across boundaries where a single profiler view will not tell the whole story.

How Aspire can provide better context to Copilot

A separate video focuses on how .NET Aspire can make GitHub Copilot's coding agent more effective by giving it structured app context, continuing last week's theme that “agentic” workflows get more reliable when the tooling supplies governed, repeatable context instead of relying on ad-hoc prompts. The pitch is concrete: one-command startup for the app's containers and processes (plus debugger wiring), and Aspire-provided skills for common tasks like profiling, resource commands, and deployment, with OpenTelemetry context helping the agent reason about the running system.

If you are experimenting with agentic workflows, the key idea is that “context” is not just source code. Being able to reliably stand up the full app graph and expose standardized knobs for operations is what makes an assistant's suggestions easier to validate and less likely to drift away from what actually runs.

Local AI agent evaluation in .NET with Microsoft Agent Framework and Ollama

Running local evaluator pipelines with built-in checks

Picking up from last week's Agent Framework coverage (loops, routing, and production-readiness), two tutorials dig into evaluating AI agents locally in .NET using Microsoft Agent Framework with a local Ollama model. The first focuses on building an agent and validating it with LocalEvaluator plus built-in checks like KeywordCheck and ToolCalledCheck, which helps confirm both response content and whether the agent invoked tools when expected.

This matters if you want faster feedback loops and fewer external dependencies while iterating on prompts, tool schemas, and safety constraints. Local evaluation is also easier to integrate into pre-commit or CI when you want deterministic-ish gates around “did the agent follow the plan” behavior.

Writing custom evaluators (content and structure)

The follow-up shows how to write custom evaluators with patterns like content-focused and structure-focused checks, using a FunctionEvaluator style approach and running them through the local evaluator pipeline. The practical benefit is being able to enforce your own rubric (for example required fields, output schema, or “must cite source”) instead of relying only on generic quality checks.

If you are building internal copilots or tool-using agents, custom evaluators are one of the more straightforward ways to prevent regressions as prompts evolve. They give you a place to encode the expectations your downstream systems actually have, like strict JSON output or mandatory tool calls.

Code scanning: CodeQL 2.27.0 adds Linux ARM64 support

CodeQL 2.27.0 added native Linux ARM64 support, which is a practical improvement if your code scanning runs on ARM-based runners or you want parity with ARM64 build environments. The release also includes analysis improvements like expanded framework modeling for C# and Java/Kotlin (including ASP.NET Core MVC-related modeling called out in the notes), plus new and refined Rust queries.

There are also updates around GitHub Actions evaluation for author-association checks, which can matter for organizations tightening policy around what code scanning and automation runs on pull requests. If you maintain custom CodeQL workflows, this is a good time to validate runner architecture assumptions and re-baseline alerts as the modeling changes.

Other .NET News

Following last week's .NET Conf 2026 timeline setup as the checkpoint for .NET 11 readiness, the .NET community calendar is warming up with the call for presenters open on Sessionize from Sep 8 to Oct 6 and Community Days scheduled for Nov 12-13. If you have a migration story (including .NET 11 RC-to-RTM), tooling lessons, or a focused deep dive, this is the window to propose it.

VS Code also shipped a couple of lighter items: a new “VS Code pet” you can launch from Copilot Chat via the /vscode-pet slash command (and a naming contest), plus a quick tip on switching file icons using the Catppuccin icon theme. These are small, but they reflect how VS Code is continuing to blend editor UX tweaks with Copilot-driven entry points.