Weekly .NET Roundup: Modernization, Agents, and Legacy Hosting

by TechHub

This week in .NET is about making upgrades and AI features easier to run in real systems. Azure App Service Managed Instance reached GA, giving .NET Framework and Windows-dependent apps a more production-ready landing zone while you plan longer-term modernization. On the tooling side, Visual Studio and Copilot content focused on turning migration into a repeatable workflow (assessment, planning, checkpoints) that scales to large solutions and dependency graphs. In parallel, the AI story moved from single features to agentic architectures, with routing and failover in Microsoft.Extensions.AI, local-first Agent Framework patterns, and quality control loops that put reliability into application logic.

This Week's Overview

Azure App Service Managed Instance reaches GA for legacy .NET apps

Managed Instance on Azure App Service is now generally available, giving teams a more PaaS-like landing zone for Windows-dependent and .NET Framework workloads that are hard to move to Linux App Service or containers without a rewrite. The pitch is “minimal code changes” while still getting App Service management and platform integration, which is useful for line-of-business apps tied to Windows features and older dependencies.

The GA release fills in a lot of the production checklist items: Premium v4 plan support, zone redundancy, and stronger observability so you can operate these apps with fewer custom diagnostics add-ons. It also tightens security and governance defaults with managed identity enabled by default, plus Azure Policy and Microsoft Defender for Cloud coverage, which matters for orgs that have to prove compliance controls across the platform.

For migration planning, the announcement calls out infrastructure-as-code support (Bicep and Terraform) and integration with Azure Migrate, which should make it easier to standardize repeatable moves across many apps and environments. Building on last week's durable execution patterns for long-running .NET workloads on App Service, this GA option gives legacy .NET Framework apps a more production-ready App Service target while you plan the longer modernization path.

Copilot-assisted modernization becomes a more concrete workflow

Across Visual Studio and the .NET content this week, the common thread is turning “modernization” into something more procedural: assess, plan, then execute in small, verifiable steps. The practical focus is on moving older .NET Framework codebases forward (often to .NET 10), while managing the dependency and compatibility traps that usually derail large upgrades.

Guided upgrades from .NET Framework to .NET 10 in Visual Studio

Microsoft's walkthrough shows a Copilot-driven modernization experience inside Visual Studio that uses guided checkpoints to keep the work structured: assessment, planning, and step-by-step execution. The example upgrade goes from a .NET Framework sample app to .NET 10, including the kinds of changes that typically require careful sequencing, like migrating ASP.NET to ASP.NET Core and moving from Entity Framework 6 to EF Core.

For teams, the value is less about “Copilot writes code” and more about reducing the coordination overhead of an upgrade by making the next step explicit and reviewable. This is especially relevant when you need to upgrade incrementally while keeping a legacy app deployable, because checkpoints map well to PR-sized changes and staged rollouts.

Scaling modernization to large solutions and dependency graphs

A separate .NET session frames modernization as a workflow problem in multi-project solutions: inventory dependencies, identify compatibility issues early, and systematically resolve blockers as you move projects forward. The emphasis is on using Visual Studio 2026 and GitHub Copilot to reduce time spent on repetitive edits and to help untangle large-solution friction points like transitive dependencies and version mismatches.

In practice, this is the gap between “a demo upgrade” and “the real estate portfolio upgrade” where different projects move at different speeds. If you are planning a staggered upgrade, the key takeaway is to treat dependency management as a first-class part of the plan, not as cleanup after the compiler errors stop.

Building deterministic migration tooling with Copilot

Rather than using AI only for one-off edits, this guidance focuses on using GitHub Copilot to help create deterministic migration tools for package version changes or swapping libraries, which echoes last week's point that agent and tooling workflows work best when actions are reproducible across environments (dev boxes, CI, and review). That approach matters because a scripted or tool-driven migration can be repeated across many repos, validated, and rolled back, which is hard to do reliably with manual AI-assisted refactors.

For developers, the practical pattern is: use Copilot for scaffolding and iteration speed, but keep the output deterministic (explicit rules, repeatable transforms, predictable diffs). This makes AI assistance fit better into CI and code review, especially when migrations touch many projects.

Building “intelligent .NET apps” moves from features to agentic architectures

The .NET AI content this week keeps drawing a line from adding AI features (summarization, classification, semantic search) to building agent-style systems that can plan and use tools. The recurring theme is making these systems dependable: unify how you call models, add routing and failover, and introduce quality control loops when outputs matter.

Microsoft.Extensions.AI: unified model access with routing and failover

Routing and failover for Microsoft.Extensions.AI highlights a resiliency strategy for when a model or provider becomes unavailable. Instead of hard-coding a single provider, the idea is to define policies that can route requests to alternate models and retry in a controlled way, keeping user-facing features running even when an upstream model endpoint is degraded.

For teams shipping AI features in production, this is the difference between “AI is a best-effort add-on” and “AI is part of the core path” where outages must be handled gracefully. If you're already abstracting model calls, this is a natural next step: codify provider fallback and decide which operations can tolerate retries vs. which should fail fast.

From AI features to agentic systems with Microsoft Agent Framework

Building on last week's emphasis on production-ready agents (approvals, tool definitions, and observability), the “intelligent .NET applications” roadmap starts with practical features you can ship using Microsoft.Extensions.AI (summarization, classification, semantic search) and explicitly includes both cloud-hosted and local model options. It then layers in agentic designs using Microsoft Agent Framework, which shifts the problem from “call a model” to “coordinate multiple steps, tools, and decisions.”

This framing is useful if you're trying to keep scope under control: ship narrow AI features first, then expand into tool-using agents when you have telemetry and failure modes understood. It also reinforces that local models are part of the strategy, not an afterthought, which can matter for privacy constraints or offline workflows.

Quality control loops and Copilot SDK integrations for local-first agent workflows

Following last week's thread of IDE- and SDK-driven agent experiences (Copilot SDK hooks and structured agent frameworks), two tutorials show how to wire agent workflows together in .NET 10 using Microsoft Agent Framework with Ollama for local model execution. One focuses on integrating the GitHub Copilot SDK into an agent-style workflow, and the other demonstrates a judge-driven quality control loop where a “worker” model produces an answer and a “judge” model evaluates it, allowing up to three retry iterations (implemented with patterns like a LoopAgent).

The practical takeaway is that reliability work is shifting left into application logic: you do not just prompt better, you add evaluation and retries with explicit limits. If you're building internal tools where models run locally for cost or privacy reasons, these examples show a concrete architecture for adding guardrails without depending on hosted evaluation services.

.NET 11 direction: web, desktop, and language features

Alongside near-term modernization and AI patterns, Microsoft is continuing to signal where .NET 11 is headed across ASP.NET Core, Blazor, and desktop development. For teams planning upgrades, these discussions help separate what is stable today (shipping on .NET 10) from what is likely to influence architectural choices over the next release.

ASP.NET Core and Blazor priorities in .NET 11

Building on last week's Preview 7 coverage (where Blazor performance and lifecycle improvements were a concrete signal of what .NET 11 is optimizing for), the .NET 11 discussion outlines the themes shaping upcoming work in ASP.NET Core and Blazor rather than focusing on a single feature drop. That is useful context if you are deciding whether to invest in certain patterns now or wait for platform-level improvements, especially for Blazor apps where hosting models and performance characteristics can influence design.

Treat this as planning input: align your current architecture with the direction of travel, but keep major bets grounded in what exists in your current target runtime. For teams with long-lived web apps, having a rough sense of platform priorities can help you time refactors around framework changes.

WinForms modernization and upcoming .NET 11 desktop work

The WinForms session focuses on how AI-assisted development is changing day-to-day workflows for both migrating legacy WinForms line-of-business apps and starting new ones. It also calls out updates in the WinForms designer and previews of upcoming .NET 11 features, which is relevant if your desktop UI work is gated by tooling limitations as much as runtime capabilities.

If you maintain WinForms at scale, the practical angle is using AI assistance to speed up repetitive UI and event-handler work while keeping the migration path predictable. The note about a “WinForms Expert Agent” reinforces the broader pattern in this roundup: specialized assistants that apply consistent rules can be more useful than generic code generation.

C# language work: union types and new extension concepts

A C# update digs into recent and upcoming language features, with a focus on union types for expressing closed sets of shapes. That is especially relevant for wire-protocol and API scenarios where you want the compiler to enforce “these are the only valid variants,” rather than relying on conventions and runtime checks.

The same discussion touches on extension members and closed classes, continuing the theme of making APIs easier to model and evolve safely. If you build libraries or public APIs, these features (when they land) could reduce boilerplate and make versioning less error-prone by pushing more invariants into the type system.

VS Code and Copilot updates that matter for .NET workflows

Even when the announcements are not .NET-specific, VS Code and Copilot changes affect everyday .NET development because they shape editing, debugging, and chat-assisted workflows. This week's items are a mix of “what's new” walkthrough content and pointers to the latest Insiders iteration, which is often where extension authors and early adopters validate compatibility.

Recent VS Code + Copilot features in practice

Building on last week's VS Code and Copilot UX notes (where the focus was on day-to-day chat and editor workflow refinements), VS Code Live provides a walkthrough of recent Visual Studio Code and GitHub Copilot updates, with attention on Copilot Chat and how the experience is evolving in the editor. These live demos are most useful for teams standardizing on a workflow, because they show what is actually shipping and how it behaves, not just what is described in release notes.

If you are rolling out Copilot to a team, this kind of overview can help you set expectations about where Copilot fits well (interactive exploration, iterative edits) and where you still need strong review and tests (refactors, security-sensitive changes).

VS Code 1.135 Insiders: track changes early

The VS Code 1.135 Insiders notes are primarily pointers to the GitHub commit log and the closed issues list for the 1.135.0 milestone. For .NET developers, Insiders builds are mainly relevant if you rely on extensions (C#, Dev Kit, MAUI tooling, Azure tooling) and want early signal on regressions or API changes that could affect your setup.

If you maintain internal dev environment docs, this is a good moment to remind teams to pin stable versions for day-to-day work and reserve Insiders for evaluation. Keeping that separation reduces “it broke on my machine” churn when the editor updates faster than extensions do.

Other .NET News

Several sessions this week focused on how to make day-to-day .NET development more reliable and productive, especially when AI tools are part of the workflow. The recurring message is to combine diagnostics, structured context, and targeted tooling rather than expecting one tool to solve everything.