Weekly .NET Roundup: Agents, Blazor WASM, and Secure Deployments

by TechHub

Welcome to this week's Weekly .NET Roundup, where the theme is making modern .NET systems easier to run in the real world: from durable, orchestrated AI agents to more predictable Blazor WebAssembly performance and testing. We look at the Host Integration Server 2028 preview bringing .NET 10, Linux support, Entra ID, and Arc governance to IBM integration scenarios, plus new guidance that turns the Microsoft Agent Framework into something you can build, host, and observe like any other service. We also cover secure-by-default agent deployments with an azd template, practical .NET 10 minimal API versioning patterns, and a steady stream of Copilot and VS Code updates that push agents, context control, and reproducible workflows into everyday development.

This Week's Overview

Host Integration Server 2028 preview brings .NET 10, Linux, and modern auth to mainframe integration

Microsoft Host Integration Server (HIS) 2028 entered preview with a clear theme: keep the IBM connectivity story, but update the platform around it. Building on last week's focus on .NET 10 as a new Linux baseline (Ubuntu 26.04, aligned container tags), the preview targets .NET 10, adds Linux support for non-SNA features, and introduces new REST API surfaces aimed at making DB2 and CICS/IMS integrations easier to consume from modern apps and services.

For teams running hybrid estates, the preview also folds in Microsoft Entra ID for identity and Azure Arc for management, which shifts HIS from a “Windows integration server” mindset toward something you can govern alongside the rest of your fleet. The post also calls out deprecations intended to remove legacy components, which is a practical signal to audit existing deployments and identify any dependencies that could block an eventual upgrade.

.NET agent development matures: orchestration patterns, durability, DI, and production hosting

Microsoft's Agent Framework guidance this week largely focused on the “how do we build this like software” questions: routing between agents, making workflows durable, structuring skills with dependency injection, and deploying with identity and observability. Taken together, the posts push the framework beyond demos and toward repeatable application architecture.

Handoff orchestration for bounded multi-agent graphs

The Handoff orchestration pattern describes a bounded agent graph where agents route control using injected handoff tools while preserving a shared transcript. The key design point is that you define the graph up front, then let agents decide when to hand off, which can be a better fit than strictly sequential workflows or hard-coded conditional branching when responsibilities are clear but the path is not.

The guide includes both .NET and Python examples, and it frames the decision as a trade-off: Handoff for flexible routing inside a constrained graph, Sequential for more linear work, and explicit conditionals when you need deterministic control. If you're already building multi-agent flows, this is a concrete pattern to standardize how agents transfer context and ownership without losing traceability.

Durable workflows with Durable Task and Azure Functions hosting

Durability is one of the first pain points when an agent-driven workflow spans minutes or hours, touches external systems, or needs retry semantics. The durable workflow post shows how to use the Durable Task runtime with the Agent Framework workflow model, including running parallel agents with fan-out/fan-in and resuming state safely after restarts.

It also covers hosting workflows on Azure Functions and optionally exposing tools through MCP (Model Context Protocol), which matters if you want the same workflow to be callable from different agent runtimes or developer tools. The practical takeaway is that you can treat long-running agent work more like workflow orchestration (state + checkpoints + retries) than like a single chat session.

Production deployment with Foundry Hosted Agents (identity, rollouts, observability)

The “local to production” guide walks through deploying Agent Framework agents to Foundry Hosted Agents in Azure AI Foundry, with details that matter once you leave the dev box. It covers packaging containers via azd and Azure Container Registry (ACR), choosing protocols (including /responses vs invocations), and using Microsoft Entra ID for identity.

It also calls out operational needs: versioned rollouts and built-in observability via Application Insights. If your team is piloting agents, this is a useful reference for turning an agent into a deployable service with the same expectations you would apply to any production API.

Agent Framework v1.0 building blocks: sessions, memory, tools, and workflows

A companion overview positions Microsoft Agent Framework v1.0 as a core .NET building block alongside tool calling and the surrounding Microsoft.Extensions.AI ecosystem. It highlights key primitives like AgentSession, memory via context providers (for example, an AIContextProvider), and graph-based workflows for multi-agent orchestration.

If you're evaluating whether to adopt the framework, this post is the architecture map: where “agent” logic sits, how sessions and memory are modeled, and how tools and workflows compose. It also helps clarify which concerns belong in skills/tools vs the workflow layer, which tends to reduce rewrites later.

DI for class-based skills (and running with a local LLM via Ollama)

A separate tutorial focuses on day-to-day .NET ergonomics: dependency injection with class-based skills. It shows resolving services inside an AgentSkillResource function so skills can be tested and composed like other ASP.NET Core components, instead of becoming static helpers or tightly coupled singletons.

The walkthrough also demonstrates running an agent against a local LLM via Ollama, which is useful for developers who want to iterate without sending every prompt to a hosted model. The combination (DI-friendly skills + local model loop) makes it easier to build a workflow you can debug and unit test before worrying about production hosting.

Blazor and .NET WebAssembly: performance work in .NET 10 and testing previews in .NET 11

Blazor-related news split in two directions this week: real-world WebAssembly performance work already shipping in products, and a testing story that is still in preview. Both threads point toward “Blazor as an app platform” becoming more operationally predictable, not just easier to build with.

Copilot Studio migrates from .NET 8 to .NET 10 on WebAssembly

Copilot Studio moved its .NET WebAssembly runtime from .NET 8 to .NET 10 and shared the specific knobs that made the upgrade worth it. The write-up highlights built-in asset fingerprinting and the new default WasmStripILAfterAOT behavior, along with measured performance improvements when using AOT (ahead-of-time) compilation.

For Blazor WebAssembly teams, this is a practical checklist of where .NET 10 can change real app behavior: smaller or cleaner outputs after AOT, better caching behavior with fingerprinted assets, and tangible performance uplift you can validate with your own benchmarks. It also builds on last week's .NET 11 Blazor direction (virtualization and UX primitives) by showing the platform side of the story: .NET 10 changes that materially affect shipping Blazor apps today.

E2E component testing for Blazor (first look, targeting .NET 11)

A Blazor Community Standup previewed a new end-to-end component testing library planned for .NET 11. The demo focused on testing components against real applications (not just isolated unit tests), which tends to be where Blazor teams struggle today when validating routing, authentication, JavaScript interop, and full UI behavior.

Because the library is still early, the main action for teams is to track the direction and provide feedback on the testing model and APIs before they harden. Following last week's .NET 11 Blazor previews (validation and better list virtualization), this is another signal that the team is filling in the “non-demo” gaps that make large Blazor apps easier to maintain.

VS Code + GitHub Copilot: Agents, CLI workflows, and enterprise guardrails in recent releases

A run of VS Code point releases (1.113 through 1.118) kept expanding the Copilot surface area, especially around agents and CLI-driven workflows. The common thread is that Copilot is becoming less “chat in the sidebar” and more a set of orchestrated tools (agents, subagents, sessions, evaluation, context controls) that you can tune and operationalize.

Agents Window and agent-centric workflows land in the editor

Recent updates highlighted VS Code Agents and an Agents Window, positioning the IDE as a place to manage agent-driven tasks rather than only request single responses. Alongside agents, releases continued improving supporting UX like the integrated browser and a customizations welcome page, which signals a push to make agent configuration and onboarding less opaque.

If your team is experimenting with multi-step Copilot flows, the practical implication is that more of the workflow now fits inside VS Code itself, reducing the need to bounce between separate tools. Keep in mind that multiple videos emphasized that some Copilot features vary by plan and can be restricted by enterprise policy, so rollout may require coordination with admins.

Copilot for CLI gets more “tooling”: MCP, remote control, and session debugging

VS Code 1.113 called out Copilot CLI improvements including MCP support, session forking, and debug logs, plus model-picker controls like “thinking effort” for scenarios where you want to trade cost/latency for deeper reasoning. Later updates (including 1.118 and the April highlights) added remote control for Copilot CLI sessions, making it easier to supervise or drive longer CLI-based tasks.

For developers, the key change is that CLI sessions are increasingly treated as artifacts you can inspect, troubleshoot, and manage, not just one-off commands. If you are standardizing Copilot-assisted workflows in CI, dev containers, or internal tooling, features like session forking and debug logs are the difference between “it failed” and “we can reproduce and fix the workflow.”

Managing context and cost: semantic indexing, skills context, and token billing

VS Code 1.118 highlighted semantic indexing with GitHub text search, dedicated context for skills, and token-based billing considerations. Together, these features push Copilot usage toward a more explicit model: what context the agent can see, how it retrieves it, and what it may cost when scaled across a team.

Teams should treat this as a cue to document their Copilot setup the same way they document build tooling: define which repos and indexes are used, how skills are scoped, and what policies apply. It is also a good moment to add lightweight governance, such as default instructions and constraints, before usage grows organically and becomes hard to control.

UX polish: chat customization, subagents, and better handling of outputs

VS Code 1.113 and 1.114 leaned into quality-of-life improvements: chat customization options, nested subagents, and small but practical changes like copying the final Copilot Chat response and troubleshooting prior chat sessions. There was also a note about video previews in the image carousel, which matters if you're relying on rich context in chat exchanges.

These improvements are easy to overlook, but they reduce friction when you are iterating on prompts, instructions, and agent behavior. If you are building internal prompt guides or team workflows, the ability to copy final responses cleanly and revisit prior sessions makes documentation and reproducibility simpler.

Secure-by-default AI agent deployments with azd (Curity + Entra ID + token exchange)

A new Azure Developer CLI (azd) template from Curity and Microsoft packages an AI agent app around a least-privilege authorization model. The template uses short-lived OAuth 2.0 JWTs and token exchange, and it includes Microsoft Entra ID plus Curity Identity Server, API gateways with audit logging, and a layered Bicep deployment targeting Azure Container Apps.

For .NET teams building agent-backed APIs, the value is not just the infrastructure automation, but the reference architecture: keep tokens short-lived, scope access via claims-based authorization, and put auditing at the gateway. It also follows naturally from last week's “repeatable environments” thread (dev containers, Linux baselines) by showing what “repeatable” needs to include for agents in particular: identity, gateways, and audited boundaries, not just a working dev setup.

Practical .NET 10 web API guidance: versioning minimal APIs with Asp.Versioning.Http

A hands-on tutorial showed how to add API versioning to a .NET 10 Minimal API using Asp.Versioning.Http, including both query-string and URL-segment versioning. It also walks through how to deprecate an API version, which is often the missing piece when teams adopt versioning but never operationalize retirement.

The demo uses a Visual Studio 2026 .http file for testing, which is a lightweight way to keep versioning checks close to the codebase without standing up extra tooling. After last week's look at aligning API versioning with OpenAPI output, this is a useful “from the other side” follow-up that focuses on the mechanics of adding versioning to minimal APIs and keeping it enforceable as versions age out.

.NET client and UI experimentation: MAUI with Rust/SkiaSharp and real-time AI/ML processing

The .NET MAUI Community Standup showcased experiments that blend native performance techniques with cross-platform UI. Demos covered Rust integration, “SkiaSharp everywhere” rendering, a drawn-UI approach, and AI/ML live processing work, which together point to teams pushing MAUI beyond standard controls into custom rendering and compute-heavy scenarios.

For app developers, the interesting part is the architecture options: using SkiaSharp for consistent rendering across platforms, leaning on Rust for performance-sensitive components, and treating AI/ML processing as a first-class live pipeline. Coming right after last week's MAUIDevFlow inner-loop walkthrough, this continues the same theme of tightening the MAUI feedback cycle while exploring performance headroom that standard control stacks do not always reach.

Copilot-assisted refactoring and customization: from repo-wide plans to an “agent stack” of files

Two pieces this week focused on making Copilot workflows more repeatable: one at the “big refactor across a repo” level, and one at the “how do we configure Copilot like we configure software” level. The common thread is moving from ad-hoc prompting to structured intent, roles, skills, and task workflows that teams can share.

Multi-file refactoring with GitHub Copilot Workspace

GitHub Copilot Workspace was presented as an intent-driven workflow for planning and executing multi-file refactors, including a concrete example that modernizes authentication from password-based logic to a token-based approach with dependency injection. The emphasis is on the planning view and turning that plan into pull requests, which is where multi-file changes usually fall apart when driven by plain chat.

For .NET teams, this is a realistic use case: auth refactors touch configuration, middleware, DI wiring, and multiple endpoints, so the “plan then apply” approach fits better than iterative one-file edits. It is also a reminder to treat Workspace output like any other change set: run tests, check security assumptions, and review diffs with the same rigor as human-written refactors.

The “Copilot customization stack”: AGENTS.md, instructions, skills, prompts, and roles

A separate guide mapped out a five-file customization approach for GitHub Copilot: AGENTS.md, scoped .instructions.md files, SKILL.md skills, .prompt.md workflows, and .agent.md roles. The example uses a .NET Aspire repo to show how each layer activates during a real task, which helps teams understand what belongs in global guidance vs repo-scoped constraints vs reusable skills.

If you're trying to make Copilot behavior consistent across a team, this structure provides a vocabulary and a place to put things. It also builds on last week's push toward more repeatable workflows (especially dev containers and standardized environments) by treating agent behavior itself as configuration you can version, review, and roll out deliberately.

.NET game development content grows: new show plus Unity + MCP walkthrough

Microsoft Developer launched “Quest to Compile,” a new show aimed at game developers building in the .NET ecosystem, covering fundamentals like gameplay programming and debugging alongside workflows like Git and AI-assisted development with GitHub Copilot. In parallel, a Unity-focused tutorial showed how to connect GitHub Copilot to the Unity Editor using MCP (Model Context Protocol) and build a playable prototype from prompts, including setup steps, permissions, and guidance around instructions, agents, and skills.

For developers, the connective tissue here is practical: game dev in .NET is increasingly about tooling and iteration loops, not just language choice. If you're experimenting with Copilot inside a game workflow, the MCP setup details and the focus on permissions and best practices are the parts to copy, because they determine whether AI assistance helps or becomes noise.

Other .NET News

Two retrospective talks this week added context around why Microsoft's developer platforms look the way they do today. Amanda Silver revisited the original motivation for TypeScript as a way to add structure and scalability to large JavaScript apps, while Mark Russinovich explained why Win32 is still a first-class API surface in 2026 due to Windows' compatibility commitments and ecosystem realities.