Weekly .NET Roundup: Tooling Defaults, AI Building Blocks, and APIs

by TechHub

This week in .NET was a mix of platform plumbing and practical building blocks: Microsoft pushed forward on modernizing the toolchain (especially inside Visual Studio), while several posts showed how .NET 10+ apps are increasingly composed from focused libraries for AI, caching, and API surface management. Coming right after last week's split between “install the preview” (.NET 11 Preview 3) and “patch production now” (April 2026 servicing), the throughline is familiar: the platform keeps tightening defaults (dependencies, provenance, project systems), and teams need to validate those shifts early to avoid surprises later. At the same time, a couple of changes signaled where the ecosystem is heading next, including a notable test platform dependency shift that could surface as a breaking change in CI.

Visual Studio and the .NET toolchain are getting more “SDK-style” (with a few sharp edges)

Visual Studio 18.5 added official SDK-style project support for VSSDK-based VSIX extension projects, which is a meaningful quality-of-life improvement if you maintain extensions that have historically lived in older project system land. The headline is that SDK-style enables better incremental builds, including the Fast Up To Date Check, so inner-loop iteration on extensions should feel closer to modern .NET projects. Microsoft also shipped updated templates and provided a short migration checklist to help existing extensions move over without guesswork, which matters because extension projects tend to accrete custom MSBuild logic over time. Seen next to last week's SDK/CLI “inner loop” focus in .NET 11 Preview 3 (dotnet watch resiliency, CLI edits for solution filters, and other iteration tweaks), this is another step in the same direction: more of the ecosystem moving to the newer project system conventions so tooling can be faster and more predictable. In the same “tooling modernization” vein, VSTest announced it is removing its Newtonsoft.Json dependency starting in .NET 11 Preview 4 and Visual Studio 18.8. The new default is System.Text.Json, while .NET Framework scenarios will use JSONite. This is partly motivated by keeping dependencies tighter and responding to ecosystem pressure around NuGet vulnerabilities, but it has real compatibility implications: adapters, collectors, and any test infrastructure that assumed Newtonsoft.Json was present transitively may fail at runtime. The guidance is straightforward but important for extension authors and test tooling maintainers: explicitly reference Newtonsoft.Json if you still need it, and check any serialization behaviors that change when moving to System.Text.Json. It is also a clear continuation of last week's “keep your inputs trustworthy” theme (signed official .NET container images, servicing patches, and deadlines that force modernization): the platform is steadily removing implicit assumptions and nudging teams toward explicit dependencies and maintained defaults.

SkiaSharp 4.0 Preview 1 modernizes graphics primitives and expands targets

SkiaSharp 4.0 Preview 1 landed with a jump to Skia milestone 147 and a focus on newer typography and drawing APIs. Variable fonts (OpenType variable fonts) and color font palettes are the kind of features you only notice once you try to render modern design systems across platforms, and having them supported at the library level reduces the need for platform-specific workarounds. The preview also introduces SKPathBuilder, which should make constructing complex paths more ergonomic and potentially less error-prone than manual path mutation patterns. On the platform side, the release adds new native targets and ships an interactive gallery implemented with Blazor WebAssembly, which is a practical way to let developers verify rendering behavior quickly without pulling down a full sample solution. The post also calls out Uno Platform co-maintenance, continuing the theme that SkiaSharp sits at the intersection of Microsoft and cross-platform UI communities. With last week's .NET 11 Preview 3 spending time on browser/WASM packaging and debugging (including WebCIL) and on UI ergonomics like Blazor Virtualize improvements, SkiaSharp's Blazor WASM gallery fits the broader pattern: .NET-in-the-browser tooling is becoming a more normal part of how libraries demonstrate and validate cross-platform behavior.

Composable AI in .NET: a reference app that stitches together the stack

ConferencePulse is a good example of how Microsoft wants teams to build AI features in .NET: not via one monolithic framework, but by composing smaller pieces. The tutorial walks through using Microsoft.Extensions.AI as the application-facing abstraction, then layering in DataIngestion and VectorData for retrieval-augmented generation (RAG)-style Q&A. It also pulls in MCP (Model Context Protocol) and the Microsoft Agent Framework to drive tool-based workflows like poll generation, plus multi-agent session summaries and real-time insights. What makes the walkthrough useful is that it is not only about prompting. It treats ingestion, vector storage, and tool execution as first-class parts of the app, and it runs under .NET Aspire with Azure OpenAI, so you can see how the pieces hang together in a real deployment shape (including OpenTelemetry for observing the system). If you're deciding whether to adopt these new “Extensions.*” AI packages, this is one of the clearer end-to-end examples of how they are intended to be wired. It also mirrors last week's preview theme of “small primitives that reduce custom glue” (for example, more built-in knobs in System.Text.Json and other BCL areas): the composable approach is showing up across the stack, not just in AI.

Performance and interop patterns: tiered caching and Native AOT DLL exports

On the performance side, Microsoft demonstrated tiered caching in a .NET 10 app using HybridCache with Azure Database for PostgreSQL as the distributed cache (via Microsoft.Extensions.Caching.Postgres). The core idea is to combine an in-memory layer for fast hits with a shared Postgres-backed layer for cross-instance reuse, then measure the difference between cold and warm paths. The tutorial stays grounded in implementation details you actually need in a real service: configuration, secrets handling with dotnet user-secrets, and a simple benchmark setup that highlights lower latency on cache hits once the pipeline is warmed. Last week's .NET 11 Preview 3 leaned heavily into runtime/JIT optimizations and hot-path wins without code changes, and this caching walkthrough complements that story from the app architecture side: even as the runtime trims overhead, teams still get big, measurable wins by designing for warm paths and shared state across instances. For interop-heavy teams, Rick Strahl showed how .NET Native AOT can publish a Windows-native WinAPI-style DLL from a .NET 10+ class library, including exporting functions via UnmanagedCallersOnly and publishing with dotnet publish. The guide is candid about constraints: when you want to be callable from non-.NET code (like older tools such as FoxPro), you have to think in terms of stable exported entry points, StdCall conventions, and limited marshalling scenarios. The payoff is a deployment artifact that looks like a traditional native DLL while still being authored in C#. In a week where VSTest is explicitly changing transitive dependencies (and last week emphasized keeping containers and servicing baselines current), Native AOT is another example of the same practical pressure: be explicit about what you ship, what you depend on, and what contracts you expose, because “it was there implicitly” is becoming less reliable over time.

API surface and reliability: versioned OpenAPI and the outbox pattern, revisited

API versioning continues to be a practical concern for teams shipping public endpoints, and the .NET 10-focused guide on combining Asp.Versioning v10 with OpenAPI shows a clean pattern: generate one OpenAPI document per version and expose them as versioned endpoints like /openapi/v*.json. The post covers both controllers and Minimal APIs, then shows how to wire SwaggerUI or Scalar so consumers can browse the right contract without guessing which version a given schema belongs to. For teams trying to keep backward compatibility without freezing their API design, “one OpenAPI per version” tends to be easier to maintain than a single blended spec that grows conditional logic. It also ties back to last week's reminder that frameworks and timelines move on (like the ASP.NET Core on .NET Framework end-of-support date): clear, versioned contracts make it easier to evolve APIs while you modernize runtimes and hosting models underneath. Reliability in distributed systems showed up as well via On .NET Live, where Joao Antunes revisited the transactional outbox pattern using his OutboxKit toolkit. The discussion centers on the core trade-off the pattern is meant to address (atomicity between database state changes and message publishing), what tends to go wrong in real implementations, and alternative approaches when the operational cost of an outbox is too high for a given system.

Other .NET News

Visual Studio 2026 18.6 Insiders 3 now enables the TypeScript 7 Beta native preview by default, prioritizing compiler and language service performance while calling out feature gaps and known issues you will want to validate against your solution (especially if you rely on specific editor behaviors). The update also intersects with how teams manage project-local TypeScript via npm, since the “native language service preview” changes the default experience inside the IDE. It lands in the same broader “defaults are changing” bucket as the VSTest JSON dependency shift: IDE and tooling updates can quietly alter day-to-day behavior, so pinning versions and validating upgrades in CI matters.