Weekly .NET Roundup: .NET 11 Preview, Patch Tuesday, and Agent Tooling

by TechHub

This week's Weekly .NET Roundup spans three practical threads: getting ready for platform changes, tightening security posture, and making AI-assisted development more repeatable. We cover the Logic Apps shift toward Azure Functions out-of-proc hosting on the road to .NET 10, plus .NET 11 Preview 5 and June 2026 servicing fixes you should roll into SDK mirrors, container images, and CI. On the tooling side, MCP shows up in build-log investigation and assistant skills, while agent middleware patterns and OpenAI-compatible endpoints point toward production-ready agent hosting. We also look at a real npm supply chain compromise that matters to polyglot .NET pipelines, and hands-on database guidance for Postgres performance, temporal modeling, and RAG at scale.

This Week's Overview

Azure Logic Apps shifts toward Azure Functions out-of-proc hosting for .NET 10

Azure Logic Apps is preparing a hosting-model migration that moves workflows from the in-proc model to an Azure Functions out-of-proc model as part of the road to .NET 10 support. The key control point is the LOGICAPP_INPROC_REDIRECT app setting, which determines whether existing apps automatically redirect from in-proc to the new out-of-proc hosting path.

If you deploy Logic Apps using NuGet-based packaging, this is not a “set it and forget it” change. You need to update how your deployment is structured before the redirect can be removed, otherwise you risk breakage when the platform stops supporting the legacy in-proc path. Treat this as a near-term migration task: validate your hosting model, confirm what the redirect is doing in each environment, and adjust your build/release pipeline so your artifacts align with the out-of-proc expectations (which fits the same “make hidden defaults explicit” theme we highlighted last week across .NET builds and security tooling).

.NET platform releases: .NET 11 Preview 5 plus June 2026 servicing fixes

This week combined forward-looking platform work (a new .NET 11 preview) with “patch now” servicing guidance for supported runtimes. If you maintain production apps on .NET 8/9/10, the servicing release details matter for security posture and upgrade scheduling, while the preview highlights show where SDK and framework behaviors are heading next.

.NET 11 Preview 5 adds new SDK/runtime/library capabilities (and more MCP tooling)

.NET 11 Preview 5 is out with updates spanning the runtime, SDK, and core libraries, plus feature work across ASP.NET Core, .NET MAUI, and Entity Framework Core. Highlights called out include System.Text.Json updates, a LINQ full outer join capability, X25519 support, SDK vulnerability checks, a new MCP Server template, Blazor SSR updates, and EF Core changes.

For teams experimenting with newer workflows, the MCP-related items are a recurring theme this cycle, building on last week's coverage of MCP governance extensions by pushing the ecosystem toward more standardized agent and tool integration points. If you test previews in CI, this is a good time to validate build reproducibility and any analyzer or SDK behavior changes, especially if you rely on locked-down dependency policies.

June 2026 servicing: security fixes for .NET 10.0.9, 9.0.17, and 8.0.28

Microsoft shipped June 2026 servicing updates for .NET 10.0.9, 9.0.17, and 8.0.28, including fixes for CVEs (including CVE-2026-45591, CVE-2026-45491, and CVE-2026-45490) across the runtime and ASP.NET Core. The release also points to installers, container images, Linux packages, and known issues so you can align workstation, CI images, and production base images.

Notably, .NET Framework has no new updates this month, so the action is focused on modern .NET, and it pairs naturally with last week's “audit-by-default” NuGet direction: you want both patched runtimes and dependency auditing to keep the vulnerability signal trustworthy. If you manage fleets, the practical next step is to update your container base images and internal SDK mirrors, then run regression tests that cover TLS/crypto surfaces, JSON serialization hot paths, and ASP.NET Core request processing where security fixes commonly land.

AI-assisted .NET development gets more structured: MCP for builds, skills for assistants, and agent middleware patterns

A clear theme this week was turning “AI help” into repeatable tooling you can trust in day-to-day engineering. The updates ranged from build-log investigation via Model Context Protocol (MCP), to a skills-based approach for more idiomatic .NET output, to guidance on middleware patterns that harden agent behavior in production.

Microsoft Binlog MCP Server (preview) lets assistants query MSBuild .binlog files

The Microsoft Binlog MCP Server (preview) exposes 15 tools via MCP so AI assistants (including GitHub Copilot) can interrogate MSBuild .binlog files for diagnosing failures, tracing property values, analyzing performance, and comparing builds. It plugs into the existing Structured Log Viewer ecosystem, including its search DSL, and is positioned to work across Visual Studio, VS Code, and CLI-centric setups.

In practice, this makes build troubleshooting more queryable: instead of skimming massive logs, you can ask targeted questions about why a property resolved a certain way, what targets dominated build time, or what changed between two runs (a practical continuation of last week's “make agent work observable and reviewable” storyline, now applied to build diagnostics). For teams with large solutions and intermittent CI failures, the “compare builds” angle is particularly useful because it can shorten the path from “it failed” to a concrete diff you can act on.

dotnet/skills focuses on more accurate, idiomatic .NET code from assistants

The ASP.NET Community Standup introduced dotnet/skills, which aims to improve assistant output by grounding generation in specific “skills/tools” and validating behavior using real-world evaluation scenarios. The emphasis is not just correctness, but idiomatic .NET and ASP.NET Core patterns that match how teams actually build and maintain apps.

For developers adopting AI tooling, the practical takeaway is to prefer assistants wired into explicit tools and evaluation loops over free-form prompting alone, extending last week's “plan first, then act” agent workflow into “teach and test the assistant” so outputs hold up in review. If you're standardizing AI usage across a team, this kind of skills-based approach can reduce style drift (and subtle framework misuse) that otherwise shows up later as review churn.

Agent Framework middleware and OpenAI-compatible endpoints show “production shape” for agents

On .NET Live, a deep dive into Microsoft Agent Framework middleware showed how layering middleware around ChatClient can address real production failure modes like cost spikes, privacy leaks, and unsafe tool calls, while staying close to an ASP.NET Core middleware mental model. The practical benefit is composability: you can add logging, policy, guardrails, and routing as discrete layers instead of scattering concerns across prompt code.

A separate tutorial showed how to expose a .NET agent via an OpenAI Chat Completions-compatible HTTP endpoint using an ASP.NET Core Empty project, then run the agent against a local Ollama model (gpt-oss) for development and testing. That combination (middleware patterns + protocol-compatible endpoints) builds directly on last week's focus on governance and tracing for agents: you can host agents like any other ASP.NET service, enforce policies consistently, and still keep provider choice and local testing in reach.

Supply chain security: Mastra npm compromise used postinstall malware and .NET injection techniques

Microsoft Defender Security Research detailed a large-scale supply chain compromise in the mastra/@mastra npm ecosystem, starting with a typosquat dependency that executed a malicious postinstall dropper. That initial stage fetched a second-stage implant and established cross-platform persistence, turning a routine dependency install into an execution path for malware.

For .NET teams, the write-up is a reminder that modern build pipelines are polyglot and your risk profile is defined by the entire toolchain, not only NuGet, reinforcing last week's emphasis on dependency hygiene and reducing restore-graph noise so real alerts stand out. The analysis calls out indicators of compromise (IOCs), mitigation steps, and KQL queries for Microsoft Defender XDR Advanced Hunting, and it also touches on attacker techniques like reflective .NET assembly injection and abuse scenarios around CI/CD identity (including GitHub Actions OIDC). If your .NET builds run npm installs (frontend bundling, tooling, or SDK integrations), review postinstall policy, lockfiles, and your CI environment isolation assumptions.

Data and PostgreSQL: temporal modeling differences, burstable-instance pitfalls, and RAG architectures

This week's database content stayed grounded in operational reality: how temporal semantics differ across engines, how burstable cloud behavior can trigger cascading failures, and what a production RAG stack looks like when Postgres is the backbone. The common thread is that “it works in dev” assumptions break down quickly under real constraints like CPU credits, indexing trade-offs, and auditability requirements.

Temporal features: SQL Server temporal tables vs PostgreSQL 18 temporal constraints

A .NET Data Community Standup compared SQL Server temporal tables with PostgreSQL 18's new temporal constraint functionality, emphasizing that the two features differ in meaning and design even if they sound similar. For teams using Entity Framework Core across multiple backends, this matters because you cannot assume a one-to-one mapping between “temporal” features when you change providers or introduce multi-database support (which complements last week's EF Core performance focus by pushing teams to be explicit about query and schema semantics, not just provider APIs).

The practical implication is to model temporal requirements explicitly: do you need system-versioned history tables, enforced time-period constraints, or both? That decision affects schema design, migration scripts, and how you expose time-aware queries in your data access layer.

Burstable instances and Postgres latency: simulate CPU-credit depletion to find the cliff

A POSETTE 2026 talk walked through how CPU credit depletion on burstable cloud instances (for example Azure B-series) can trigger cascading PostgreSQL latency spikes and timeouts. The presenter used a .NET-based discrete-event simulation (including a token-bucket style model for credits) to estimate saturation points and guide tuning decisions like connection pool sizing.

For developers running Postgres-backed .NET services on burstable SKUs, the takeaway is to treat CPU credits as a first-class capacity constraint, extending last week's “build discipline that holds up under scale” from CI and service conventions into infrastructure selection and performance modeling. When credits run out, what looks like a mild load increase can become a step-change failure, so modeling and pool sizing help you avoid the “everything times out at once” scenario.

Production RAG on Azure Database for PostgreSQL: pgvector, DiskANN, and Semantic Kernel

Another POSETTE session outlined Serenity Star's production retrieval-augmented generation (RAG) architecture built on Azure Database for PostgreSQL. The talk covered pgvector for semantic search, DiskANN indexing for scaling vector retrieval, and integration via Microsoft Semantic Kernel, with attention to production concerns like scaling and monitoring.

If you're building .NET RAG services, this is a concrete reference architecture that lines up with last week's agent observability theme: once RAG becomes a dependency for agent behavior, you need the same monitoring and performance discipline for retrieval and indexing as you do for your services. Pay attention to indexing choices and monitoring signals early, because vector search performance and recall can drift as data volume and query patterns evolve.

Modernization in the .NET ecosystem: Aspire workflows, CLI-driven migration, and “agentic modernization”

Microsoft continued pushing modernization content that favors incremental upgrades and operational visibility over rewrites. The week included Aspire-centric onboarding flows, guidance on migrating legacy .NET Framework apps, a CLI path to Azure, and an “agentic modernization” framing that ties modernization work to adding AI agent capabilities.

Aspire as an onramp to distributed apps (and an onboarding path for existing projects)

.NET Aspire was spotlighted both as a community project and as a practical modernization tool that models distributed app components and dependencies with a unified workflow for running and troubleshooting multi-service systems. The “Stop Rewriting. Start with Aspire.” walkthrough showed an onboarding flow using aspire init and the Aspireify agent skill, demonstrated on the MVC Music Store app, and it called out OpenTelemetry as part of the story for observability.

If you're modernizing a multi-service .NET system, Aspire's value is in making the local dev and troubleshooting loop more consistent across services, dependencies, and environments, picking up directly from last week's Aspire Dashboard tracing work by keeping observability and workflow consistency tied together. It is also a way to introduce better telemetry and dependency modeling early, which reduces the “it only fails in staging” gap that shows up when services proliferate.

Migration helpers: Copilot-assisted upgrades and Modernize CLI for Azure readiness

A dotnet video demonstrated using GitHub Copilot to assess and execute modernization work for legacy .NET Framework apps, focusing on planning and migration scenarios that reduce risk during upgrades to modern .NET. In parallel, the Modernize CLI was presented as a faster, CLI-driven workflow for modernizing and migrating .NET applications to Azure, aimed at getting to cloud-ready deployments with less manual setup.

These approaches are complementary, and they echo last week's modernization guidance to start with assessment reports and stepwise execution: Copilot can help with code and planning tasks, while the CLI can standardize repeatable steps in automation. If you're building an internal modernization playbook, the immediate practical step is to identify the parts you can codify (CLI/pipelines) versus the parts where interactive assistance helps (code changes, analysis, incremental refactors).

“Agentic modernization” frames modernization as the path to adding agents

Several items leaned into the idea that modernization is not only about upgrading runtimes and architectures, but also about enabling new capabilities like AI agents. The “.NET Day of Agentic Modernization 2026” event video collected this theme, while “Modernize .NET Apps and Add Agentic Functionality in Minutes” positioned agent features as an incremental add-on once the app is in a healthier state.

A separate On .NET Live session provided an in-depth introduction to agentics, including where agents fit in the broader AI ecosystem and how patterns like RAG support agent behavior, extending last week's thread on governed execution by tying agent readiness to the same incremental modernization steps teams already use for reliability and security. If you're evaluating whether to add agent workflows to an existing product, this week's content suggests a sensible order of operations: stabilize and modernize the app, then add agent capabilities behind clear boundaries (APIs, middleware, and policy controls) rather than embedding them everywhere.

IDE and database tooling: Copilot workflows, theming, VS Code updates, and SSMS DevOps features

This week's tooling updates skewed toward small workflow improvements that add up in daily use: tighter Copilot controls, ways to standardize prompting, IDE customization for teams, and better database project support. None of these change your architecture, but they can reduce friction across coding, review, and release processes.

Visual Studio: reusable Copilot prompt files and live theme token overrides

A tutorial showed how to create reusable prompt files in Visual Studio 2022 for GitHub Copilot, with the goal of standardizing prompts across common tasks. This is most useful when teams want consistent outcomes for repetitive work like writing tests, generating documentation, or performing refactors with agreed constraints and style.

Visual Studio 2026 (18.7) added a Theme colors options page that lets you customize Fluent color tokens live in the IDE and share per-theme overrides via JSON. For teams, JSON-based overrides make it easier to align accessibility preferences or reduce “theme drift” across developer machines without relying on each person to hand-tune settings (a natural continuation of last week's shift toward more structured, governable agent workflows by standardizing inputs and expectations in the editor).

VS Code + Copilot: model providers, token budget visibility, BYOK, and UI polish

VS Code 1.125 updates included a visual indicator for when Copilot uses additional token budget, plus a simpler workflow to add/install model providers, with notes about enterprise policy controls and plan-based availability. VS Code 1.126 (Insiders) followed with smaller UI refinements, including chat/Agents UI tweaks like spinner alignment, a unified model customization picker for context/reasoning effort, and inline chat renaming.

The broader thread is more explicit model and cost control in the editor, building on last week's VS Code agent telemetry and remote-agent coverage by adding clearer signals for budgeting and configuration alongside observability. Knowing when you're consuming extra budget and having clearer ways to configure models matters if you're rolling Copilot out in an enterprise environment. Related content highlighted “bring your own key” (BYOK) support so developers can use provider API keys without signing in, expanding model choice while changing how teams think about governance and billing.

SSMS 22.7: schema compare, SQL formatting, and better SQLCMD variable support

SQL Server Management Studio (SSMS) 22.7 shipped updates aimed at SQL projects and database DevOps workflows. The release added a graphical schema compare experience, a built-in configurable SQL formatter with format-on-save, and improved SQLCMD variable support in the Publish dialog and via SqlPackage.

For teams maintaining DACPAC-based deployments, these changes reduce toolchain fragmentation: schema diffs and consistent formatting can happen inside SSMS, and improved SQLCMD variable handling helps close the gap between local publishing and automated release pipelines (and they fit the same general “reduce review noise” thread we covered last week with dependency graph pruning). If you're standardizing database changes through pull requests, schema compare plus formatting rules can also make reviews easier by reducing noise in diffs.

Other .NET News

VS Code highlighted a lightweight way to render Mermaid diagrams directly in Markdown Preview, notebook Markdown cells, and VS Code Chat via the Mermaid Markdown Features extension. This is a small but useful upgrade for teams that keep architecture notes and runbooks in-repo and want diagrams to render consistently where they write and review.

A .NET MAUI Community Standup covered the move of .NET MAUI to CoreCLR in .NET 11 and profiling tooling via MAUI Labs, including trade-offs between startup time and APK size. If you ship mobile apps, it is a reminder to validate performance and package size as part of your upgrade testing, not after you move the runtime.

Modernization strategy content continued with a practical decision-making story around a 2005 WinForms line-of-business app (maintain as legacy vs invest as a modern desktop asset) and guidance on modernizing data-centric systems by migrating the database first behind stable API layers. Together, they reinforce an incremental approach: define what you keep stable (APIs, user workflows), then modernize the parts that unblock cloud-native operations and ongoing delivery (which mirrors last week's modernization theme of planning and assessment before execution).