Weekly .NET Roundup: Durable MCP Tasks, NuGet OIDC, .NET 11

by TechHub

This week's .NET roundup centers on making agent and MCP workloads reliable in the real world, from durable long-running tasks on Azure App Service to the stateless-first direction in MCP C# SDK 2.0. On the security and supply chain front, NuGet.org is capping API key lifetimes (pushing teams toward OIDC-based Trusted Publishing), while ASP.NET Core in .NET 11 preview expands automatic CSRF defenses using Fetch Metadata headers. We also cover practical developer experience updates, including richer CI test reporting in Microsoft.Testing.Platform, Blazor performance and lifecycle tweaks in .NET 11 Preview 7, and a concrete local AI sample for live speech-to-text with Foundry Local.

This Week's Overview

Durable MCP tasks and agent execution patterns on Azure

Building on last week's focus on making MCP servers more observable and repeatable (sampling and log surfacing), long-running MCP (Model Context Protocol) “tasks” are starting to look less like in-memory jobs and more like distributed workflows, and this week had a clear theme: make task state durable, make execution replaceable, and assume the client will disconnect. One practical pattern is to split “what is happening” (task state) from “where it is running” (work execution) so a scaled-out app can safely resume, cancel, retry, and approve work across instances.

On Azure App Service, a durable approach stores task state in Azure Table Storage while pushing the actual work to Azure Service Bus, which gives you a stable task identity even if the web process restarts or a different instance picks up the next step. Managed Identity fits naturally here for both storage and messaging access, so you can avoid connection strings while still supporting reconnects, cross-instance approvals, and safe retries in a multi-instance deployment.

A smaller but useful companion idea shows the same philosophy at the MCP tool level: return a task handle immediately, run the tool in the background, and have the client poll until completion. If you are building MCP servers in .NET today, this is a concrete starting point for “async tools” that do not block request threads and that degrade gracefully when the caller cannot hold a long-lived connection.

MCP C# SDK 2.0 and the push toward agent-friendly .NET tooling

This week reinforced that .NET's MCP story is converging on interoperability and “stateless-first” communication, while IDE and platform tooling is increasingly oriented around agents that can plan, call tools, and ask for approvals.

MCP C# SDK 2.0: stateless-first, HTTP support, and multi round-trips

MCP C# SDK 2.0 landed with a stateless-first design that aims to make MCP clients and servers easier to scale and host, especially when you cannot rely on sticky sessions. Updates called out this week include standardized HTTP support, improved interoperability, support for multi round-trip requests, and backward compatibility to reduce upgrade friction for existing implementations.

For .NET developers building agents or MCP servers, the practical shift is to treat session state as something you externalize (or reconstruct) rather than something you assume will live in a single process. That lines up with the durable task patterns above and makes it easier to host MCP endpoints in cloud environments where instances come and go.

Visual Studio agent preview and the Copilot SDK hook

Building on last week's VS Code agent UX refinements, Microsoft also teased a Visual Studio AI agent preview built on the GitHub Copilot SDK, signaling that agent experiences are moving from “chat plus suggestions” toward workflows that can take actions and coordinate tools. If your team has been experimenting with agents in editors, this is another indicator that the IDE will increasingly be the orchestration surface, not just the place where code is typed.

In practice, that means more scenarios where your internal tools need clean, well-authenticated APIs (including MCP servers), and where approvals, logs, and audit trails need to be first-class. As these previews mature, expect more pressure to standardize tool contracts and to make actions reproducible across environments (local dev boxes, CI, and hosted agents).

Building production-ready agents with Copilot Harness and Microsoft Agent Framework

Following last week's Agent Framework updates around Harness and Declarative Workflows 1.0, GitHub Copilot's “harness” is being positioned as the execution engine for agents, while Microsoft Agent Framework provides the structure around it: tool definitions, streaming, approvals, and observability. This week brought a stable GitHub Copilot Agent for Microsoft Agent Framework in both .NET and Python, along with guidance and code samples that focus on the parts teams struggle with in production (permissions, session handling, and safe tool execution).

A key detail for .NET teams is how directly this ties agent work to MCP: the post walks through configuring MCP servers, wiring custom tools, and using human-in-the-loop approvals to gate actions that should not run unattended. Observability gets explicit attention too, including OpenTelemetry, which matters when an agent can trigger multiple tool calls across services and you need to reconstruct “why did it do that” after the fact.

If you are already experimenting with Copilot CLI/SDK, this release reads like a recommended architecture: keep the agent runner consistent (harness), model tools in a framework that supports streaming and approvals (Agent Framework), and treat MCP servers as the integration boundary so tools remain portable. The code-first focus (permissions, session management, and tooling configuration) makes it easier to evaluate this as a real project pattern, not a demo.

Security and supply chain: TLS fixes, NuGet key lifetimes, and new ASP.NET Core CSRF defenses

Fix WCF Relay listeners now that TLS 1.0/1.1 are retired

If you still run .NET Framework WCF Relay listeners against Azure Relay, TLS retirement can show up as sudden connection failures rather than a gradual degradation. The remediation guidance this week focuses on getting clients to negotiate TLS 1.2+ reliably, with options that range from app-level configuration to explicit code changes and machine-wide settings.

One common fix path is to force TLS 1.2 in code via ServicePointManager, but the post also covers configuration and registry approaches depending on how locked down your environment is. The important takeaway is operational: if you have older relay listeners in production, validate their effective TLS settings and rollout plan now, because this is the kind of dependency break that can hide until a restart or redeploy.

NuGet.org caps API key lifetime at 30 days (move to Trusted Publishing)

NuGet.org is tightening supply chain security by capping API keys at 30 days starting August 17, 2026, and expiring all keys created before that date on November 1, 2026. If you publish packages from CI with long-lived secrets, this is an immediate workflow risk: your pipeline may start failing on key expiration unless you rotate keys continuously.

The recommended path is NuGet Trusted Publishing, which uses OpenID Connect (OIDC) so CI systems can mint short-lived identity tokens instead of storing reusable secrets. For teams on GitHub Actions or Azure DevOps, this is the nudge to migrate now: remove API keys from secret stores, switch to OIDC-backed publishing, and treat package publishing like any other modern federated auth flow.

ASP.NET Core (.NET 11 preview) adds Fetch Metadata-based CSRF protection

Picking up from last week's .NET 11 Preview 6 roundup (where automatic CSRF protection was one of the headline “safer defaults”), ASP.NET Core in .NET 11 preview 6 adds automatic CSRF protection that uses Fetch Metadata headers, which let the server reason about how a request was initiated (same-site, cross-site, navigation, etc.). The new middleware (discussed with an “allow/deny” algorithm) complements token-based antiforgery instead of replacing it, and it matters most for endpoints that are otherwise hard to protect with tokens (for example, some GET-like navigations or scenarios where you want a baseline defense without wiring tokens everywhere).

The write-up goes into how this interacts with existing frameworks (Minimal APIs, Blazor SSR, MVC, Razor Pages) and where CORS allow lists and request classification fit into the decision. For teams planning a .NET 11 upgrade, it is worth testing early because security middleware can surface surprising edge cases, especially if you have cross-origin integrations, embedded apps, or unusual navigation flows.

Testing and diagnostics: better failure context in Microsoft.Testing.Platform

Microsoft.Testing.Platform is getting more serious about the “red build to root cause” loop by surfacing failures directly where developers triage them. New reporting capabilities add GitHub Actions annotations and Azure DevOps integration so failing tests show up with richer context rather than forcing developers to download artifacts and manually inspect logs.

Azure DevOps gets extra history-based signals, including flaky-vs-regression classification and slow-test context based on prior runs, which helps teams decide whether to fix the test, fix the code, or quarantine a noisy suite. Another practical improvement is resilience: the platform aims to preserve usable reports and artifacts even when the test host crashes, which can turn a previously opaque failure into something actionable.

Format support also matters for toolchains and dashboards, and the post calls out TRX, JUnit XML, and CTRF outputs. If you maintain custom CI reporting or ingest test results into third-party systems, this is a good time to check which formats you rely on and whether the new annotations reduce the need for bespoke glue.

.NET 11 Preview 7: Blazor performance and lifecycle improvements

Building on last week's Preview 6 focus on safer defaults and sharper web APIs, this week's ASP.NET community standup called out changes that directly affect real apps. Output caching for Blazor is a notable addition for teams pushing SSR (server-side rendering) and trying to reduce repeated rendering work for content that does not change per request.

QuickGrid virtualization improvements continue the focus on large-data UI scenarios, where scrolling performance and DOM size can make or break usability. Blazor Server circuit auto-pausing is another pragmatic feature, aiming to reduce resource usage by pausing inactive circuits instead of holding server resources indefinitely for idle clients.

These are preview features, so the practical advice is to prototype them in a branch and watch for compatibility issues in your component and hosting setup. If you have been waiting for better caching and large-list behavior in Blazor, this preview cycle is worth tracking closely.

Local AI in .NET: Foundry Local live speech-to-text

Running models locally is becoming a standard requirement for teams with offline, privacy, or latency constraints, and this week had a concrete .NET example for speech. A Windows-only .NET 10 console app demo shows live speech-to-text using Foundry Local, including catalog-based model resolution, model download and caching, and streaming interim and final transcriptions.

On the implementation side, the sample uses Microsoft.AI.Foundry.Local plus common .NET building blocks like async streams, System.Threading.Channels, and NAudio for audio capture. If you are evaluating “local first” AI features in a desktop or edge app, this is a useful reference for how to structure streaming inference so the UI (or caller) can react to partial results rather than waiting for a full transcription.

Developer tools: VS Code Copilot UX and extension author tweaks

Following last week's emphasis on VS Code's Agents window and how Copilot workflows are becoming more “in-editor,” VS Code's recent updates keep focusing on day-to-day usability in Copilot Chat and the editor shell rather than big platform shifts. Version 1.132 highlights Copilot Chat session activity tracking (helpful when you have multiple threads going), side chats via /btw, terminal output reflow, and improved dictation onboarding and customization, with some features depending on enterprise settings and plan entitlements.

For extension authors tracking Insiders, VS Code 1.133 adds a small but targeted capability: custom editor extensions can set different default priorities for normal editing versus diff views. That matters if your extension should take over editing a file type in the editor but should not interfere with diff workflows (or vice versa), and it can reduce the need for awkward user instructions around “disable this for diffs.”

A separate short tip highlights IntelliSense in the integrated terminal, which is low-impact but useful if you want to keep command-line work inside VS Code with fewer typos. None of these are .NET-specific, but they directly affect the inner loop for .NET developers living in VS Code.

Other .NET News

Microsoft highlighted its placement as a Leader in Gartner's 2026 Magic Quadrant for AI-augmented code modernization tools, framing GitHub Copilot modernization plus Azure as an agentic workflow for assessment, upgrade, migration, and validation with developer review, testing, and security checks. If you are planning legacy .NET modernization, the useful angle is the named building blocks (for example, a Modernize CLI and agent workflows) that you can map to your own governance and review requirements, even if you treat the analyst recognition as secondary.

GitHub code scanning also shipped CodeQL 2.26.2, adding Swift 6.3.3 and Kotlin 2.4.10 support and updating several queries (including GitHub Actions-related queries) that may produce more findings. There is also a breaking change around alert message link formatting, so teams that post-process alerts or rely on link parsing should validate their automation after upgrading.