Weekly .NET Roundup: NuGet Signing, Agents, Dumps, and .NET 11

by TechHub

This week in .NET centers on production readiness: Microsoft rotated its NuGet author-signing certificate (which can break locked-down restores), while agent building guidance moved from demos to deployable systems with AG-UI, memory, isolation, and secret redaction patterns. On the operations side, repeatable dump capture and Visual Studio analysis workflows showed how to diagnose real production hangs like thread pool saturation. We also saw steady momentum in platform hygiene, from .NET 11 preview security hardening (including experimental DBSC) to CodeQL improvements and Azure Functions expanding managed connector triggers in public preview.

This Week's Overview

NuGet package signing change: update trusted signer policies now

Building on last week's “shipping and hardening” thread (especially the emphasis on servicing cadence and CI hygiene), Microsoft rotated its default author-signing certificate for NuGet packages starting September 23, 2026, which can break restores and CI pipelines if you pin trusted signers. If your environment enforces signature validation, expect errors like NU3034 until you add the new certificate fingerprint (SHA-256) to your allow-list and update any dotnet nuget verify or policy checks.

This is mostly a plumbing change, but it matters because it fails “loudly” in automated builds and locked-down enterprise machines. Review where you enforce package signature rules (developer machines, build agents, internal NuGet proxies) and update configuration before your next restore. If you publish packages, this is a good time to re-check how you validate upstream dependencies and whether you rely on older certificates in your compliance process.

Building production agents with .NET: interoperable UIs, isolation, memory, and safe execution

Following last week's local evaluation focus (Agent Framework + Ollama) and the broader move from experiments to reliable workflows, this week connected several pieces of the “production agent” story in .NET: a standard protocol for interactive experiences (AG-UI), Agent Framework updates for memory and execution, and concrete guidance for isolating and persisting agent state in Azure AI Foundry. The common thread is moving from demos to deployable systems where identity, state, and failure recovery are first-class concerns.

AG-UI gets a first-class .NET SDK (typed events, SSE, and Extensions.AI)

The AG-UI protocol now ships with an official .NET SDK, so .NET services can expose and consume agent endpoints using typed AG-UI events rather than ad-hoc JSON. The quickstart shows an ASP.NET Core setup that streams events over Server-Sent Events (SSE), and the SDK integrates with Microsoft.Extensions.AI so you can plug in an IChatClient without rewriting your application architecture.

A notable ecosystem detail is that the Microsoft Agent Framework is migrating to a shared AGUI.* implementation, which should reduce protocol drift between “framework” agents and custom service implementations. If you have internal tools that need a consistent interactive surface (chat, tool calls, status events), AG-UI gives you a clearer contract and a path to typed handlers across services.

Microsoft Agent Framework: memory providers, interactive endpoints, CodeAct, and resilient hosting

The latest Microsoft Agent Framework update focuses on pieces you typically discover only after shipping: interactive experiences via AG-UI endpoints, semantic memory through Foundry-backed context providers (including a FoundryMemoryProvider), and “resilient execution” for long-running workflows that must survive restarts. The post also calls out CodeAct execution with Hyperlight, positioning it as a safer way to run agent-driven code paths in a more isolated environment.

For .NET developers, the practical takeaway is that the framework is increasingly opinionated about production concerns: state management, execution boundaries, and recoverability. If you are building agents that need durable context, or background work that cannot rely on a single process lifetime, this release maps directly to architecture decisions (where memory lives, how you replay work, and what execution model you trust).

Foundry hosted agent isolation: user isolation vs hosted session isolation, delegated identity, and agent_session_id

A separate guidance post dug into isolation controls for Foundry hosted agents, distinguishing between user isolation (keep one user's data from another) and hosted session isolation (separate sandboxes for execution and state). The mechanics matter: you provide delegated identities (via Microsoft Entra ID) and manage agent_session_id to choose between stable per-session sandboxes and pooled designs where you reuse sessions across workloads.

If you are building multi-tenant agents, this helps you make isolation explicit instead of accidental. It also frames how you think about “memory” and “tools” in practice: what persists across turns, what persists across sessions, and what must never leak across users even when you pool compute to control costs.

Durable agent memory and troubleshooting in the wild (Foundry + Blob Storage + real migration pitfalls)

Episode 7 of The Upload paired agent durability with very practical operational issues: agent isolation plus durable memory using Microsoft Foundry and Azure Blob Storage, along with a reminder that real systems still fail in mundane ways (like time-data migration problems between PostgreSQL and SQL Server). The segment is a useful “week-in-the-life” snapshot of where teams spend time once AI features and services hit production: state, data correctness, and reliability.

If you are designing agent memory, treat “durable store” as a requirement, not an add-on, and decide what belongs in a vector store versus blobs versus relational tables. On the database side, time and timezone semantics are still a top source of bugs during migrations, so plan for validation queries and integration tests that compare behavior across engines rather than only schema compatibility.

Guardrails: redacting secrets before they reach the model

Picking up from last week's emphasis on evaluator checks and repeatable gates for agent behavior, a hands-on tutorial showed how to prevent secrets (passwords, API keys) from being sent to an LLM by inserting redaction middleware into a .NET helpdesk agent built with Microsoft Agent Framework and Ollama. The key idea is to treat secrecy as part of the agent pipeline (like logging or auth), not as a prompt-writing exercise, and to apply redaction consistently to user input, tool output, and any retrieved context.

If you are building agents that touch internal systems, this pattern is worth copying early. It gives you a central place to enforce policy and makes it easier to audit what the model could have seen if you later investigate an incident.

Azure Functions expands event and action integration with managed connectors (public preview)

Following last week's Managed Connectors-to-App Service trigger preview, Azure Functions added integration with the Azure Connector Namespace (public preview), letting you use connector triggers and typed connector clients to react to events and call actions across roughly 1,700 managed connectors. The .NET example walks through an RFP intake workflow that uses SharePoint and Teams connectors, then calls Azure AI Content Understanding to extract document content.

For .NET teams, the big shift is that connectors become a more native part of your function app architecture instead of something you wire up externally. The typed clients and DefaultAzureCredential-based authentication model should fit well with existing Azure SDK patterns, but you will want to watch limits and operational characteristics (latency, retries, idempotency) when functions are driven by connector events rather than queues or HTTP.

Diagnosing real-world failures: .NET memory dumps, thread pool saturation, and Visual Studio tooling

Building on last week's Aspire troubleshooting pattern (instrument, validate hypotheses, and use Copilot to sanity-check conclusions), memory dumps got a lot of attention this week, with complementary guidance on how to capture a dump and how to use it to pinpoint hangs that only reproduce in production. The emphasis was less on “debugging theory” and more on repeatable steps and the specific Visual Studio views that make dump analysis workable.

Creating dumps reliably (Windows MiniDumpWriteDump and Linux createdump)

A .NET tutorial covered generating full memory dumps when a process becomes unresponsive, using MiniDumpWriteDump on Windows and the runtime's createdump utility on Linux. The goal is to produce a .dmp you can open in Visual Studio and use as a forensic snapshot of the process, even if you cannot attach a live debugger in production.

If you operate services, this is a strong argument for building a “dump capture” playbook and testing it before an incident. Make sure you know where dumps land, how large they can get, and how you will handle sensitive data inside dumps when moving them off production machines.

Debugging a production hang (Parallel Stacks, thread pool saturation, and Copilot for interpretation)

A Visual Studio post demonstrated diagnosing a production hang by capturing a dump and using Visual Studio to analyze it, focusing on Parallel Stacks to identify thread pool saturation as the root cause. It also showed GitHub Copilot helping interpret what the dump was indicating, which is useful when you are staring at unfamiliar call stacks under time pressure.

For developers, the useful takeaway is methodological: a “hang” often becomes obvious once you can see blocked threads and contention patterns, but only if your dump capture is consistent and your analysis workflow is practiced. If you have sporadic timeouts, add thread pool metrics and consider guardrails (timeouts, bounded concurrency) so you fail predictably instead of saturating the pool.

.NET 11 preview thread: performance, security, and hardened sessions

Continuing last week's .NET 11 RC1 readiness push and September servicing baseline, two separate items reinforced that .NET 11 is not just about new features, but also about operational qualities like performance, security patching, and more robust authentication. If you are tracking .NET 11 previews for upcoming migrations, this week provided both a high-level “what to watch” view and a deep dive into one security-focused feature.

.NET 11 performance and security updates in context

Episode 6 of The Upload called out .NET 11 performance improvements and critical .NET security updates alongside broader Azure resiliency topics. While the segment is brief, it is a helpful reminder to treat runtime upgrades as a combination of perf tuning, vulnerability management, and reliability work, not a single checkbox.

If you maintain multiple services, plan an upgrade cadence that includes perf regression testing and a clear process for applying critical security updates. Doing that work during previews can reduce friction when .NET 11 hits your standard support window.

Experimental DBSC in ASP.NET Core (.NET 11 preview): binding cookies to a device

Andrew Lock explored experimental Device Bound Session Credentials (DBSC) support in ASP.NET Core for .NET 11, aimed at hardening cookie-based authentication by tying session credentials to a specific device. The post walks through enabling DBSC for cookie auth and ASP.NET Core Identity, and explains the registration and refresh flows over HTTP.

For many apps, the security value is reducing the usefulness of stolen cookies, but it comes with deployment considerations because device binding changes the assumptions around session portability. Since this is experimental, treat it as something to prototype and threat-model now, especially if you operate consumer-facing apps where cookie theft and replay are realistic risks.

.NET MAUI in practice: shipping a cross-platform roguelike with touch-friendly UX

A .NET MAUI Community Standup went inside GnollHack, a modernized NetHack-based roguelike built with .NET MAUI and shipped across Android, iOS, and Windows. The discussion focused on real-world cross-platform challenges: adapting gameplay to touch input, and upgrading the experience with richer audio/visuals while keeping the game's roots.

For developers evaluating MAUI, this is a useful case study because games stress UI input, rendering, and platform differences in ways that standard CRUD apps often do not. It is also a reminder that “cross-platform” is rarely free: you still have to design for each device class, especially when you move from keyboard-first to touch-first interaction models.

Security scanning for .NET repos: CodeQL 2.27.1 query and extractor improvements

Following last week's CodeQL 2.27.0 Linux ARM64 support (which simplified where and how you run scanners), CodeQL 2.27.1 shipped updates that affect GitHub code scanning across several ecosystems, including new and improved queries for C#, plus improvements to GitHub Actions queries. The release also adds Kotlin 2.4.20 support and includes extractor and data-flow model accuracy improvements, which can change both detection coverage and false-positive rates.

If you rely on CodeQL in CI, watch for behavior changes after upgrading: new queries can surface previously undetected issues, and modeling improvements can reclassify findings. It is worth budgeting time to triage “new noise” and to update any baselines or alerting rules so security teams do not miss genuinely new problems.

Other .NET News

Microsoft started a practical series on building AI-powered apps with .NET and Microsoft Foundry, leaning on live demos and SDK walkthroughs. If you are evaluating Foundry features or want reference architectures that stay close to code, this is a good thread to follow.

Two short Visual Studio Code videos highlighted small productivity tools: a set of keyboard shortcuts for faster text and column selection, and the Debug Visualizer extension for inspecting data structures while debugging. These are editor-level tips, but they can help when you are stepping through algorithms or trying to understand complex in-memory state.

A short discussion with Amanda Silver touched on how Microsoft manages open source work via documentation, upstream contributions, and collaboration patterns, using projects like Kubernetes, Apache, the Linux kernel, and VS Code as examples. It is broader than .NET, but relevant context if you depend on Microsoft-supported open source projects and want to understand the “why” behind long-running maintenance and interoperability investments.