Weekly .NET Roundup: Native AOT Testing and MCP Agent Tooling

by TechHub

This week's .NET roundup connects two practical threads: testing under real deployment constraints and building agent-style workflows you can run in production. MSTest 4.4 brings Native AOT test publishing so you can catch trimming and reflection issues earlier, while new .NET agent building blocks (Copilot SDK, lightweight harnesses, and MCP servers on Azure Functions) push tool calling and orchestration toward repeatable, auditable runs. On the day-to-day side, Visual Studio 2026 and VS Code updates focus on reducing context mistakes (scoped settings, worktrees, clearer Copilot context), and ecosystem updates like CodeQL 2.26.4 and Azure SDK releases highlight where CI and dependencies can shift under your feet.

This Week's Overview

Testing that matches production constraints: MSTest 4.4 meets Native AOT

MSTest 4.4 adds a practical missing piece for teams shipping Native AOT apps: you can now publish and run test projects as Native AOT executables using source generation. That means your tests can execute under the same trimming and reflection constraints your production deployment will enforce, instead of only passing in a more permissive JIT runtime.

The key implication is earlier detection of AOT-specific failures, especially around reflection-heavy libraries, dynamically discovered tests, and APIs that trimming can remove. This approach helps you catch issues like missing metadata and broken discovery before they show up in deployment pipelines or on customer machines.

The post walks through the configuration you need, the publish/run commands, and what changes when migrating from VSTest to the Microsoft Testing Platform. It also calls out limits and migration considerations, so you can decide whether to run AOT tests for all projects or keep AOT runs as a targeted CI job for trimming-sensitive components.

.NET developer workflow gets more “agent-shaped” (Copilot SDK, harnesses, and MCP on Azure)

This week had a consistent theme: .NET teams are getting more building blocks for agent-style apps, from in-process harnesses to production-hosted Model Context Protocol (MCP) servers, continuing last week's shift from isolated AI features to agentic architectures you can run and operate in real systems. The common thread is standardizing tool calling and orchestration so agents can reliably interact with your systems, not just chat about them.

GitHub Copilot SDK for .NET: programmatic access to the agent runtime

The GitHub Copilot SDK for .NET is positioned as a direct way to integrate with Copilot's agent runtime in your own applications. The walkthrough focuses on multi-turn conversations, tool orchestration, streaming events, and MCP-based extensibility, which is the combination you need when an agent has to call real tools and report progress as it works.

For .NET developers, the practical takeaway is that “Copilot” becomes something you can compose into your own workflows: you can route user prompts, attach tools, stream partial results, and treat the agent loop as an API surface. If you are already investing in MCP tooling, this is another path to reuse that tool contract across different hosts and runtimes.

A minimal C# harness for tracked agent runs (tools, web search, plan/execute)

dotnet also showed a lightweight approach to standing up an agent harness in C#, starting with a single AsHarnessAgent call. The demo then expands into adding a custom tool (stock price lookup), a built-in web search tool, and a plan-and-execute loop that produces tracked, step-by-step runs.

The main value here is developer ergonomics: a small amount of code gets you a repeatable harness that can log what the agent decided, what tools it called, and what happened at each step. It is also a good reminder to design tools as callable units with clear inputs/outputs, because the harness becomes most useful when you can replay and inspect failures deterministically.

Building production MCP servers on Azure Functions (tool discovery and CI/CD automation)

On the production side, Jonah Andersson walked through hosting MCP servers on Azure Functions to standardize tool discovery and invocation, which builds on last week's reliability themes (routing, failover, and quality loops) by moving the “tool layer” into a deployable, governed boundary. The example leans into real operational workflows, including an agent-driven CI/CD scenario that can create rollback PRs in Azure DevOps, which is the kind of task that benefits from a consistent tool contract and auditable execution.

If you are evaluating how to move from prototypes to deployable agent systems, this framing is useful: MCP provides a common interface for tools, Azure Functions provides a straightforward hosting model, and the surrounding practices (CI/CD, auth boundaries, logging) matter as much as the model. The talk also connects MCP with the Microsoft Agent Framework (MAF) and Azure AI Foundry, which helps if you are trying to standardize across teams.

IDE and editor updates: Visual Studio 2026 workflow polish and VS Code's Copilot/MCP tweaks

A set of smaller but concrete updates landed across Visual Studio 2026 and VS Code, mostly aimed at reducing friction in day-to-day navigation, review, and multi-context work. The interesting connective tissue is that both IDEs are treating context management (which repo, which task, which model, which tool server) as a first-class workflow problem.

Visual Studio 2026 scoped settings make multi-instance work less error-prone

Visual Studio 2026 now supports scoped settings that can apply per-solution themes, which helps when you have multiple instances open and keep switching between them. The post shows using per-solution color themes to reduce “alt-tab mistakes,” and it explains how solution-level settings are stored in settings.VisualStudio.json.

Because that settings file can be committed to source control, teams can choose to standardize certain environment behaviors per repo (or keep it local). The practical decision is governance: committing it can improve consistency, but you will want to agree on what belongs in repo-scoped settings versus personal preferences.

Git worktrees arrive in Visual Studio 2026 (less stashing, more parallel tasks)

Visual Studio 2026's August update adds a workflow around Git worktrees, letting you create a new worktree and branch without disturbing your current working directory. This is a good fit for the common interruption case: you are mid-change and need to hotfix or review something else without stashing half-finished edits.

For teams, the value is simpler parallelism: separate directories per branch reduce context switching risk and keep build artifacts isolated. If your repo has heavy build outputs or large dependency restores, you will still want to watch disk usage and ensure your tooling (formatters, analyzers, local databases) behaves well across multiple working trees.

Reviewing GitHub PRs inside Visual Studio (and feeding PR context to Copilot Chat)

Visual Studio's GitHub integration got a practical walkthrough focused on reviewing pull requests directly in the IDE: navigating diffs, leaving inline comments, approving, and merging. It also highlights a workflow detail that matters for AI-assisted review: you can attach a pull request as context in GitHub Copilot Chat via “Add to Chat” or the #pullrequest: command.

That pattern (explicitly binding artifacts as chat context) is becoming more important as teams try to make Copilot feedback consistent and reviewable, and it follows naturally from last week's focus on making modernization and refactoring work more procedural and checkpoint-driven. If you want predictable results, treat PR context like any other input: verify what was included, and prefer commands/attachments over hoping the model “knows” which PR you meant.

VS Code 1.137 (Insiders): Copilot context UX and MCP defaults

VS Code 1.137 (Insiders) includes Copilot workflow updates that mostly reduce ambiguity during prompting. A unified model token limit display makes it clearer how large your available context window is, and improved context pills when pasting GitHub issue/PR links helps you see what Copilot will actually incorporate.

The release also tweaks MCP server installation defaults for Copilot CLI and agent-host sessions, which matters if you are standardizing tool servers across developers and mirrors last week's theme that agent workflows get more reliable when the “plumbing” (context, routing, and tool contracts) is explicit. If MCP is part of your workflow, these “defaults and affordances” changes can remove setup drift, especially when onboarding new contributors or switching machines.

Security and platform plumbing: CodeQL 2.26.4 and Azure SDK updates

Two ecosystem updates are worth tracking even if you do not change code immediately: CodeQL query/model improvements can change what your CI flags, and Azure SDK package updates often unlock new service features or client behaviors. Both are the kind of “quiet drift” that can surprise you later if you do not pin versions and review changelogs periodically.

CodeQL 2.26.4: broader language support and sharper alert precision

CodeQL 2.26.4 updates GitHub code scanning with Go 1.27 support, more precise Rust data flow alert locations, and new taint models for Java/Kotlin and Python. It also improves GitHub Actions detections and adjusts C# query behavior, which can change alert volume and reduce false positives in some patterns.

For .NET teams, even when the headline is not “C# only,” CodeQL upgrades can still affect your PR gating because query packs update and actions scanning gets stricter. If you run CodeQL in CI, plan for a quick triage pass after updating to separate true regressions from detection changes.

Azure SDK release roundup: Document Translation 2.0.0, Storage Blobs beta, and AI Discovery 1.0.0 stable

The August 2026 Azure SDK roundup highlights new stable and beta packages across languages, with a few items that will matter to .NET shops via cross-language parity and service maturity. Document Translation 2.0.0 stands out as a stable milestone, while Azure Storage Blobs 12.30.0-beta.1 signals ongoing client evolution for one of the most widely used Azure dependencies.

Azure AI Discovery 1.0.0 reaching stable for Python and JavaScript is also a useful maturity signal if your organization spans multiple stacks or builds internal tools outside .NET, and it pairs with last week's “intelligent .NET apps” storyline by showing more of the AI-adjacent service surface area stabilizing across the wider Azure ecosystem. Even when you stay in C#, these release notes are a good place to spot API shifts early and align service usage across teams before your next dependency refresh.

Other .NET News

System.Text.Json and C# language features kept colliding in the .NET 11 preview story, with a detailed look at where union types and closed class hierarchies still cause friction for polymorphic serialization and deserialization. The post is especially relevant if you are experimenting with C# 15 unions or relying on InferClosedTypePolymorphism, because the workarounds (custom type classifiers and waiting for structural classifier support) affect how you model payloads and version contracts.

Tooling-wise, there were a couple of lightweight updates aimed at awareness and navigation rather than new APIs: a VS Code “Story” trailer that frames the editor's shift toward AI-era workflows, a quick Command Palette navigation tip, and a short roundup mentioning Bring Your Own Model moving into preview in Visual Studio, Foundry Models router updates, and the announced date for .NET Conf 2026.