Weekly .NET Roundup: Faster C# in VS Code and agentic apps
This week in .NET, the focus is on making everyday development workflows faster and more repeatable, from a rearchitected C# Dev Kit for VS Code to editor updates that keep Git and Copilot sessions easier to manage. On the app side, Blazor AI Components show how to build structured, tool-driven agent experiences with explicit approval steps, while Azure Functions managed connectors (preview) reduce integration code with triggers and typed clients for thousands of services. We also cover pipeline-impacting CodeQL 2.27.2 changes, a practical NativeAOT trimming technique using linker substitutions, and new guidance for reliable UWP and WinUI 3 UI testing with MSTest and Microsoft.Testing.Platform.
This Week's Overview
- VS Code and C# tooling gets a performance reset
- Building .NET apps with AI and automation: agents in the UI and connectors in the backend
- Security and analysis: CodeQL 2.27.2 updates and gotchas
- NativeAOT trimming: linker substitutions to cut dependency chains
- UI testing for UWP and WinUI 3 with MSTest 4.5 and Microsoft.Testing.Platform 2.5
- Data and database guardrails: T-SQL static analysis for AI-assisted design
- Other .NET News
VS Code and C# tooling gets a performance reset
C# Dev Kit 11.0: faster loads, lower memory, better builds
After last week's focus on production diagnosis workflows (dumps, hangs, and keeping toolchains reliable under pressure), C# Dev Kit 11.0 for Visual Studio Code ships with a rearchitecture focused on day-to-day performance: faster solution load times, reduced memory usage, and quicker incremental builds. The update targets the pain points that show up most in larger repos, where the C# extension footprint and repeated restores/builds can make VS Code feel sluggish compared to full Visual Studio.
For teams standardizing on VS Code (including dev containers and remote environments), the practical win is tighter edit-build-test loops without requiring IDE changes. The release also adds new MSBuild editing support (so project file changes are less of a context switch) and introduces a “C# Doctor” troubleshooting flow to surface common environment and configuration issues more directly.
VS Code 1.141: Git workflow polish and Copilot agent plumbing
VS Code 1.141 includes developer-experience updates that show up quickly in repo maintenance and longer coding sessions, like Git worktree storage reclamation and session layout improvements. The theme is keeping the workspace clean and resumable, especially if you juggle multiple branches or tasks in parallel.
On the Copilot side, this builds on last week's theme of making agent workflows safer and more operationally sound by leaning further into agent-style workflows: continuing external sessions, better visibility into persistent chat progress, and stronger isolation via agent host sandboxing. The release also highlights MCP (Model Context Protocol) server discovery, which matters if you are wiring Copilot or other agent tooling to external tools and data sources and want less manual configuration.
VS Code 1.142 (Insiders): track whats landing next
The VS Code 1.142 Insiders page is a pointer to the live stream of changes (commit log and closed issues) as the next release takes shape. If your team relies on specific extensions (like C# Dev Kit) or platform features (Dev Containers, Git, Copilot), following Insiders is the quickest way to spot upcoming behaviors that might affect your workflow.
For .NET teams that run on pre-release tooling in CI images or devcontainer bases, this is also where you can catch breaking UX changes early and validate that key extensions still behave as expected.
Building .NET apps with AI and automation: agents in the UI and connectors in the backend
Building on last week's “production agents” thread (AG-UI, Agent Framework memory/isolation, and Functions connectors), this week’s .NET AI story spans both ends of an app: richer agentic experiences in the UI layer, and simpler integration with external services in serverless backends. The shared theme is reducing glue code while keeping developers in control through structured workflows, typed clients, and explicit approval steps.
Blazor AI Components: structured streaming, tool invocation, and approvals
Blazor AI Components are positioned as building blocks for “agentic” user workflows in .NET apps, with features like structured streaming responses and tool invocation (tool calling). The emphasis is not only on generating text, but on orchestrating multi-step interactions where the model can call into application tools and collaborate through shared state.
A key practical detail is support for approval steps, which mirrors the guardrail patterns we covered last week (like secret redaction) by putting explicit checks in front of actions that change data or trigger side effects. If you are building internal tools with Blazor, this pushes agent integration closer to typical app UX patterns (progressive output, explicit confirmations, and shared context across a workflow) instead of a single chat box bolted onto the side.
Azure Functions managed connectors (preview): triggers and typed clients for ~1,700 services
Azure Functions managed connectors enter public preview via the Azure Connector Namespace, aiming to make Functions less about bespoke integration code and more about configuration-driven connectivity. In practice, you get connector triggers and typed clients for roughly 1,700 services, which can reduce the amount of custom HTTP/auth plumbing you maintain for common SaaS and enterprise systems.
This is a direct continuation of last week's connectors expansion coverage, with the post’s .NET example showing an end-to-end workflow: react to SharePoint uploads, process RFPs with Azure AI Content Understanding, and notify Teams using an Adaptive Card. It also highlights the .NET isolated worker path, which matters if you are standardizing on isolated for dependency management and newer hosting patterns.
Security and analysis: CodeQL 2.27.2 updates and gotchas
Following last week's CodeQL 2.27.1 query and extractor changes, CodeQL 2.27.2 rolls forward analysis improvements across multiple languages, but it also includes changes that can affect .NET teams running GitHub code scanning at scale. Even if your main codebase is C#, changes to GitHub Actions queries and CLI behavior can shift alerts and pipeline outcomes because Actions and infrastructure code often sit beside application code.
The release includes updates to C# queries and GitHub Actions security queries, plus several CodeQL CLI behavior changes that may require pipeline validation. It also documents an environmental limitation for traced analysis on macOS 27 with Xcode 27, and notes a breaking change to the Go CFG library, which matters if you maintain custom query packs or internal CodeQL tooling that depends on the Go control-flow graph APIs.
NativeAOT trimming: linker substitutions to cut dependency chains
If you are shipping NativeAOT binaries, Andrew Lock shows a concrete technique for reducing output size by making the linker smarter about what can be trimmed. The approach uses ILLink.Substitutions.xml to replace a runtime-only property with a constant, allowing the linker to eliminate a retained dependency chain (in this case, pulling in Azure.Identity/MSAL transitively) that would otherwise stay rooted.
The key takeaway is that trimming issues are not always about “unused” code in the traditional sense, but about values the linker cannot prove at build time, a theme that lines up with last week's broader push toward production readiness where build outputs and dependency policies need to be predictable. Substitutions give you a way to encode that knowledge, which can materially change what survives linking and is especially useful when a single capability (like optional auth integration) drags in a large set of assemblies.
UI testing for UWP and WinUI 3 with MSTest 4.5 and Microsoft.Testing.Platform 2.5
Testing UI frameworks often breaks the standard unit test model because work has to run on a UI thread and sometimes inside AppContainer-like environments. The new guidance explains how MSTest 4.5 and Microsoft.Testing.Platform 2.5 enable UI-thread testing for UWP and WinUI 3, covering classic and modern UWP, packaged and unpackaged WinUI, and different host options including AppContainer.
The practical value is understanding what the MSTest.Sdk is doing when it launches these tests and what your CI agents need to allow them to run, which fits the same “make the workflow repeatable” mindset as last week's operational guidance around dump capture and locked-down environments. If your pipeline has been flaky or blocked by machine policy constraints, the details on required policies and hosts can save time by making the environment requirements explicit rather than trial-and-error.
Data and database guardrails: T-SQL static analysis for AI-assisted design
Erik Ejlskov Jensen walks through an open-source T-SQL static analysis rule set designed to provide fast feedback while writing SQL, including integration with VS Code, Visual Studio, and SSMS. The twist is using those rules as guardrails when you bring AI into the database design loop, so suggestions get checked against conventions and safety rules instead of being accepted blindly.
This complements last week's real-world reminder that database work still fails in mundane ways (like time and timezone migration issues) by shifting some of that risk left into authoring-time feedback. The talk also connects this to EF Core Power Tools, framing static analysis as a way to keep AI-assisted schema and EF Core model generation aligned with team standards. For teams trying to introduce AI help without widening the “review gap,” this is a pragmatic pattern: enforce rules at authoring time and during generation, not only in code review.
Other .NET News
A few items this week focus on everyday developer ergonomics: learning paths for teams moving between ecosystems, safer handling of common C# conversions, and lightweight tooling add-ons inside VS Code.