Weekly .NET Roundup: Safer C#, cleaner NuGet, and agent ops

by TechHub

This week's .NET roundup spans language changes, dependency hygiene, and how agent-driven development fits into real engineering workflows. On the platform side, C# proposals like caller-unsafe boundaries and .NET 11 preview union types aim to make APIs more explicit and domain models easier to reason about, while Blazor WebAssembly adds a Web Worker template to move heavy work off the UI thread. In build and security tooling, NuGet package pruning and audit-by-default raise the baseline for actionable vulnerability signals with less restore-graph noise. We also look at how Copilot planning, governance extensions, and OpenTelemetry tracing (including Aspire Dashboard) are pushing agent sessions toward the same reviewability and observability standards as production services.

This Week's Overview

Safer, more expressive C# in the .NET 11 and .NET 12 pipeline

C# 16 “caller-unsafe” aims to make unsafe code boundaries explicit

The .NET team outlined a new C# 16 model that reframes unsafe as a contract with callers, not just an implementation detail inside a method. The idea is that unsafe operations must live inside explicit inner unsafe { } blocks, while method-level unsafe becomes a signal that callers are opting into that risk.

For .NET teams that use pointers, interop, or high-performance memory tricks, this change is about making boundaries visible and reviewable, and encouraging consistent documentation of safety assumptions. The proposal covers how “unsafe-ness” propagates, how you can create “boundary methods” to contain unsafe usage, and what happens across assembly boundaries.

The plan is to ship this as a preview in .NET 11 and as a production feature in .NET 12, so library authors will want to start thinking about API surface area and how they communicate safety expectations. If you expose unsafe methods today, this model may push you toward clearer layering (small unsafe cores with safe wrappers) and more intentional call sites.

.NET 11 preview union types bring exhaustiveness and clearer domain modeling

Andrew Lock dug into .NET 11 preview union types (C# 15), including the union keyword, exhaustive switch expressions, and the generated implementation patterns (IUnion and [Union]). For many apps, this is a practical alternative to loose “one-of” class hierarchies and ad-hoc discriminators, and it can make illegal states harder to represent.

The preview also matters for performance-oriented code because it discusses building custom unions that avoid boxing, using TryGetValue-style APIs to access the active case. If your codebase relies on pattern matching and discriminated unions from other ecosystems, this closes a long-standing gap in mainstream C#.

Blazor WebAssembly gets a first-class Web Worker template in .NET 11 preview

Blazor WebAssembly apps are often constrained by running most work on the UI thread, and Andrew Lock showed how the new .NET 11 webworker project template targets that directly. Building on last week's focus on making Blazor WebAssembly more predictable in real apps (performance in .NET 10 and testing direction in .NET 11), this preview adds a concrete concurrency primitive teams can adopt early to keep heavy work off the UI thread.

The post walks through adding the worker project to your solution, exporting methods with [JSExport], and invoking them from the Blazor app so CPU-heavy work can move off the main thread.

It is worth paying attention to the generated JavaScript and .NET glue code because it sets expectations about how data moves between the app and the worker (and what that means for serialization costs and API design). For UI-heavy WASM apps, this template provides a clearer starting point for background processing than hand-rolling worker infrastructure.

Dependency hygiene and vulnerability signal in .NET 10

NuGet changes in .NET 10 are pushing toward “cleaner by default” restores and more actionable security output, which helps teams that have struggled with noisy transitive graphs. This week’s update connects two pieces: package pruning (reducing unnecessary platform-provided packages in your dependency graph) and stricter auditing defaults.

NuGet package pruning reduces restore graph noise and false-positive vulnerability findings

NuGet package pruning is becoming the default in .NET 10, removing platform-provided packages from the restore graph when they do not need to be restored as explicit dependencies. A practical outcome is fewer misleading vulnerability reports that flag packages you are not actually shipping or controlling, which has been a common source of churn in security triage.

This also changes how you interpret restore outputs and dependency trees, especially if your tooling or internal documentation assumes those platform packages always show up as normal transitive dependencies. The post explains how pruning works and how it interacts with auditing, including the warnings and codes you may see in real projects (for example, vulnerability-related warnings like NU1903).

NuGetAuditMode=all becomes the default, raising the baseline for transitive auditing

Alongside pruning, NuGet is making NuGetAuditMode=all the default, which shifts more teams into auditing transitive dependencies automatically. That is helpful when you want consistent policy enforcement across repos, but it can surface new findings in builds that previously passed, so expect a period of tuning and exception handling.

The combination of pruning plus auditing is the key point: pruning aims to remove “not really your dependency” noise, while audit-by-default increases the chance you will catch real issues early. For CI pipelines, that means you should validate the new defaults against your current warning policies, and decide whether vulnerabilities fail builds or remain informational.

Copilot agents in the .NET workflow: planning first, then governed execution

This week’s .NET-adjacent tooling updates show Copilot moving beyond chat into a more structured “plan then act” workflow, while .NET libraries catch up with governance primitives for tool-using agents. Building on last week's theme of taking agents from demos to production (durability, hosting, identity, and repeatable configuration), the emphasis is now on making agent work reviewable up front and enforceable at runtime.

Visual Studio adds a Plan agent to turn Copilot Chat into an implementation workflow

Visual Studio introduced a new Plan agent that helps developers draft and refine an implementation plan inside Copilot Chat before handing off to Agent mode for code changes. The practical value is that it nudges teams to capture decisions (scope, steps, risk areas) explicitly before an agent starts editing files, which can reduce back-and-forth and improve review quality.

For .NET teams doing upgrades or refactors, this fits well with workflows where you want a written plan that can be reviewed, adjusted, and then executed in a controlled way. It also signals that Microsoft is treating planning as a first-class agent capability rather than assuming “generate code” is always the right first step.

Agent Governance Toolkit MCP extensions bring policy and auditing into .NET agent runtimes

Microsoft announced Microsoft.AgentGovernance.Extensions.ModelContextProtocol (Public Preview), a .NET 8+ companion package for the MCP (Model Context Protocol) C# SDK. The goal is to make it easier to add governance concerns with a single WithGovernance(...) builder that wires up startup tool scanning, identity-aware policy enforcement, response sanitization, and audit/metrics hooks.

If you are building internal agents that can call tools (run commands, hit internal APIs, query data stores), these features are the kind you need before wider rollout. Tool definition scanning and response sanitization help reduce accidental data exposure, while identity-aware enforcement and audit trails make it easier to meet compliance and incident response requirements.

Copilot-assisted modernization shifts toward assessment reports and stepwise execution

Two modernization walkthroughs reinforced a consistent message: start with assessment, then plan, then execute. One guide shows using the GitHub Copilot modernization agent to generate a Markdown assessment report (project scope, NuGet compatibility, and API behavior changes) before touching code, using upgrades like .NET 8 to .NET 10 as the motivating scenario.

A separate walkthrough modernizes a legacy ASP.NET Web Forms app using Copilot plan mode and agents, including security baselining, SQL Server-to-PostgreSQL migration planning, architecture visualization, and Kubernetes deployment planning with Azure modernization tooling. Taken together, they push Copilot from “do the upgrade” to “help you understand the upgrade,” which is often the missing piece in real enterprise migrations.

Agent observability shows up across VS Code, OpenTelemetry, and Aspire

This week had multiple examples of teams instrumenting agent workflows like any other distributed system, using OpenTelemetry traces and dashboards to see what an agent did and why. Following last week's push toward production hosting and built-in observability for agents, the story is now widening to include IDE-driven agent sessions as telemetry-producing workloads you can debug end-to-end.

VS Code 1.121 expands Copilot agent workflows, including remote agents and telemetry

A VS Code 1.121 update roundup focused on GitHub Copilot agent workflows, including remote agents and more explicit model configuration options. It also covered improvements around the terminal and an integrated browser, which matters when an agent-driven workflow spans editing, running commands, and validating results inside the IDE.

The notable angle for teams adopting agents is observability: the update highlights agent observability with OpenTelemetry and Grafana, making it clearer that agent sessions can be traced and reviewed like other automated processes. If you already ship OpenTelemetry from your .NET services, aligning agent traces with service traces is a practical next step for end-to-end debugging.

Tracing VS Code agent sessions into the .NET Aspire Dashboard

A separate demo showed tracing VS Code agent sessions with OpenTelemetry and then viewing that telemetry in the .NET Aspire Dashboard. It included a workflow for opening the dashboard from VS Code commands, which lowers the friction for developers to actually look at traces during day-to-day work.

For .NET teams already using Aspire for local orchestration and observability, the interesting part is treating “agent sessions” as first-class traced operations. That gives you a shared language for debugging across humans, tools, and services (spans, timelines, and correlation), instead of relying on chat transcripts alone.

Cloud-native build discipline: patterns that hold up under scale

Building cloud-native platforms is less about any one framework and more about enforcing habits that keep systems stable as teams and traffic grow. This week’s guidance framed that work as build-time disciplines aligned with the Azure Well-Architected Framework, with concrete implementation patterns many .NET shops can apply immediately.

KishoreKumarPattabiraman outlined five disciplines - flexibility, resilience, observability, delivery, and cost - and anchored them in pragmatic patterns like idempotency keys, the transaction outbox pattern, correlation IDs, and pipelines-as-code. The emphasis is that these are not runtime-only concerns: you bake them into templates, CI/CD, and service conventions so new components inherit good defaults.

For developers, the takeaway is to standardize these patterns where possible (shared libraries, API gateways, and platform templates) and to make them visible through telemetry from day one. If you are practicing trunk-based development, tying these disciplines into automated checks and deployment pipelines helps keep pace without trading away reliability.

Practical .NET development: performance, architecture choices, and better debugging

EF Core and query performance: common anti-patterns to watch for

A .NET Data Community Standup covered eight real-world query anti-patterns and fixes, with a focus on improving database query performance in common .NET and EF Core scenarios. While the talk is broad, it is most useful as a checklist for code reviews and performance investigations (where the same few patterns tend to repeat).

If your app has grown organically, using a recurring set of anti-patterns can quietly raise latency and load on your database. The value here is less “one trick” and more building shared vocabulary for spotting query shape issues early.

Rethinking MediatR: keeping pipeline behaviors without the dependency

A critique of MediatR argued that many .NET projects can remove it while keeping the benefits developers usually want, especially pipeline behaviors for cross-cutting concerns. The core point is architectural: if you only adopted MediatR for behaviors like logging, validation, and metrics, you may be able to build simpler abstractions with fewer moving parts.

For teams maintaining large solutions, this kind of dependency audit can pay off by reducing indirection and improving discoverability for new contributors. It is not an anti-pattern to use MediatR, but the discussion is a useful prompt to ensure you are getting enough value for the complexity it introduces.

Dear ImGui in .NET games: build an in-game debug layer

A .NET game dev tutorial showed how to use Dear ImGui (immediate mode UI) in .NET game projects to create real-time debugging overlays. It covered immediate mode concepts, .NET bindings like ImGui.NET and Hexa.NET.ImGui, and practical examples such as live editing values and debugging sprites or simulations while the game runs.

For developers building tools-heavy games or simulations, an in-game UI can shorten the edit-run-debug loop and reduce reliance on external debugging windows. The walkthrough is a good starting point if you are on MonoGame or similar stacks and want a lightweight way to expose runtime state safely.

Other .NET News

Several items this week sit adjacent to .NET but are still useful context for teams building on Microsoft platforms and tooling. VS Code customization is moving toward “bring your own model” setups, while security research and platform history pieces offer reminders about how ecosystems evolve.