Weekly .NET Roundup: .NET 11 Perf, Agent Apps, and ASP.NET Safety

by TechHub

Welcome to this week's .NET roundup, where the big themes are speed, agent architecture, and safer defaults. .NET 11 performance work landed across the JIT, GC, async/runtime plumbing, and core libraries, with BenchmarkDotNet-backed results that make it easier to validate wins (and explain them) in your own workloads. On the AI side, the focus shifted from isolated demos to end-to-end agent patterns using the GitHub Copilot SDK, Microsoft Agent Framework, and MCP, with practical guidance on tool scoping, orchestration, and observability. We close with a timely ASP.NET Core reminder about protecting sensitive runtime-generated files that can accidentally become public under wwwroot.

This Week's Overview

.NET 11 performance work lands across the stack

Building on last week's .NET 11 preview thread (where System.Text.Json and newer C# shapes exposed real friction points), Stephen Toub outlined hundreds of performance improvements in .NET 11 spanning the JIT, garbage collector, async/runtime plumbing, and core libraries. The write-up pairs changes with BenchmarkDotNet micro-benchmarks and links back to the underlying dotnet/runtime PRs, which makes it easier to validate gains that matter to your workload.

A lot of the practical wins come from compounding improvements rather than one switch you flip: better code generation (including more effective SIMD paths), fewer bounds checks where the JIT can prove safety, and runtime work that reduces overhead in common async patterns. Core libraries get attention too (networking, JSON, regex, collections), so teams should re-run their own perf suites when moving to .NET 11 and look for places where previously-required workarounds can be removed.

If you maintain perf-sensitive services, this is a good week to start planning an upgrade rehearsal: measure baseline numbers on your current runtime, then compare on .NET 11 with representative payloads and GC settings. The post's PR links are especially useful when you need to explain a regression or improvement to stakeholders because you can point to the exact implementation change.

Building agentic .NET apps: Copilot SDK, Microsoft Agent Framework, and MCP

Following last week's push toward “agent-shaped” .NET workflows (Copilot SDK building blocks, lightweight harnesses, and MCP servers you can run in production), this week’s .NET AI content converged on a practical theme: how to structure agent-based applications so tools are scoped safely, responsibilities are clear, and you can observe what the agent actually did. Across demos and deep-dives, Model Context Protocol (MCP) shows up as the integration layer for “tools” and services, while Microsoft Agent Framework (MAF) provides patterns for orchestration, approvals, and governance.

Interview Coach sample: agent workflow + tool calling in .NET

Building on the Copilot SDK and MCP foundations covered last week, Justin Yoo introduced the “Interview Coach” sample built on the GitHub Copilot SDK (using the Copilot CLI runtime) to run an interview coaching workflow with custom tool calling. The sample combines MCP-backed services with Microsoft Agent Framework handoffs, and it highlights implementation details that tend to trip teams up, like scoping which tools are exposed, and merging tools that become available at runtime during handoffs.

The practical setup is also very “developer workstation friendly”: you can run it locally with .NET Aspire and the Cosmos DB emulator, and there is an optional path to Azure AI Foundry for hosted deployments. If you're experimenting with agent workflows in .NET, this sample is useful as a reference for how to wire a Blazor UI to an agent loop while keeping tool boundaries explicit.

Community standup: Interview Coach evolves (MAF + Copilot SDK)

As a follow-through from last week's “building blocks” phase, Bruno Capuano and Justin Yoo followed up in the .NET AI Community Standup with updates to Interview Coach, reinforcing the same architecture from a live demo angle. The emphasis is on combining Microsoft Agent Framework with the Copilot SDK, using MCP tools behind the scenes, and presenting the experience through a Blazor UI.

For developers, the value here is seeing the pieces operate together (agent orchestration, tool calling, UI, and debugging) rather than reading them in isolation. If you're deciding whether to standardize on MAF patterns for handoffs and governance, the standup provides a clearer picture of how those concepts show up in a running app.

MafClaw live series: a C# agent harness from minimal wrapper to production concerns

This picks up directly from last week's minimal harness examples by turning the “few lines to get a loop running” idea into a guided, end-to-end build-out: Bruno Capuano announced the MafClaw live series, which builds a C# agent harness step-by-step using Microsoft Agent Framework. The outline starts small (an IChatClient wrapper) and then intentionally grows into the real-world requirements teams hit: tool wiring, planning, safe file access, approvals, memory, skills, CodeAct-style behaviors, observability, governance, evaluations, and deployment to Microsoft Foundry.

What stands out is that “production-ready” is treated as more than “it runs”: the series explicitly calls out OpenTelemetry for observability and includes governance and evaluation checkpoints. If you're building internal agents, this roadmap helps you avoid shipping an agent loop that has no audit trail, no approvals, and no way to measure behavior drift over time.

Specialist agents vs distributed skills over MCP

Continuing last week's emphasis on MCP as the tool contract you can standardize and operate, Tommaso Stocchi compared two ways to structure agent capabilities in Microsoft Agent Framework: delegating to specialist agents (A2A, agent-to-agent) versus exposing “distributed skills” over MCP. The post walks through how to migrate prompts and tools into a SKILL.md contract plus typed MCP tools, then shares execution traces to highlight differences in model-call structure, latency, and token usage.

The takeaway for builders is architectural: A2A delegation can be a straightforward mental model, but it can introduce extra hops and overhead that show up in traces. A distributed-skills approach can make capabilities more reusable and measurable (since tools are typed and traced as explicit calls), which is useful when you want to scale a set of capabilities across multiple agents or applications.

Agent-first workflows in Visual Studio Code

This week extends last week's IDE theme (making Copilot/MCP context more explicit so results are more repeatable) with a hands-on look at running and governing agent sessions in the editor: Gwyneth Pena-Siguenza demoed “agent-first development” in Visual Studio Code, focusing on how to start and run agent sessions and then keep control of what the agent can do. The tutorial covers the mechanics of agent mode, including execution environments, controlling agent functions, and using the chat debug view to understand and troubleshoot agent behavior.

For .NET developers who bounce between Visual Studio and VS Code, the key point is that debugging and governance are becoming first-class concerns in editor-based agent workflows. If you are letting an agent edit files, run commands, or call tools, you need visibility into what ran where and why, and the session controls and debug views are meant to make that auditable and repeatable.

Shipping safer apps: protecting static files under wwwroot in ASP.NET Core

Rick Strahl revisited a common footgun in ASP.NET Core: anything under wwwroot is public by default because it is served by the static files middleware. If your app generates files at runtime and writes them into wwwroot (for example exports, reports, or user-specific artifacts), you can accidentally publish sensitive content with a predictable URL.

The recommended mitigation is to insert a custom middleware check before UseStaticFiles() to block or challenge requests for paths that should not be publicly accessible. The post also calls out routing behavior and IIS reverse-proxy bypass risks, which matters if you rely on upstream rules and assume they always run before static files get served.

Other .NET News

Following last week's testing thread (Native AOT-friendly MSTest runs and more procedural agent workflows), this week also included a look back at Microsoft's path to building major developer products in the open, plus a practical guide on using Copilot's testing workflow inside Visual Studio. Both are useful context: one explains the ecosystem mindset behind the tools many .NET teams depend on, and the other shows how AI-assisted testing fits into a typical coverage-improvement loop.