Video summary

.NET 11 in depth: Runtime, libraries, and SDK for the AI era

Main summary

Key takeaways

Technology

Summary of .NET 11 (runtime, libraries, SDK) improvements (Build 2026 overview)

The speakers cover key .NET 11 work across SDK/CLI tooling, runtime libraries, and runtime-level performance and safety, with an emphasis on LLM/agent scenarios and speed/responsiveness.

SDK & tooling level improvements (.NET 11)

1) .NET SDK work streams for .NET 11

They outline three major focus areas for the .NET 11 release cycle:

  • New capabilities / user experiences
  • Performance across the stack
  • Reducing tool acquisition & management overhead (faster / smaller / easier to install)

2) CLI UX improvements for real developer workflows

A. .NET Run device deployment as a first-class workflow (MAUI)

Historically, running a MAUI app involved:

  1. build
  2. create install payload
  3. push to device
  4. launch

In .NET 11, .NET Run is enhanced so device flows are first-class:

  • dotnet run can select target framework + compatible devices
  • handles device payload upload and launch (including simulators)
  • the protocol is extensible (not limited to MAUI); they mention potential extension to UI frameworks like UNO/Avalonia

B. Agent-aware .NET CLI output (LLM context handling)

The .NET CLI detects when it’s being run under an agent/LLM context and changes behavior accordingly—especially around output rendering:

  • terminal live/dynamic updates are problematic for LLMs due to token inefficiency
  • in LLM context, the CLI can disable live updates

C. Parallel build resource contention mitigation (agent “work trees”)

Agents often spawn multiple parallel work trees (e.g., shallow clones per branch). However:

  • dotnet build historically isn’t aware of other builds on the same machine
  • this can create resource tension/contended system load

They propose strategies such as:

  • a central gatekeeper for MSBuild
  • coordinating resource delegation across concurrent builds

3) Performance: moving the .NET CLI toward Native AOT

They describe a journey to make the .NET CLI itself native AOT to improve:

  • responsiveness
  • reduced overhead per frequently-run command

Milestones mentioned:

  • bundled CLI tools (e.g., user secrets, dev certs, user JWT services) become native AOT (preview milestone referenced)

Example (user secrets):

  • total runtime ~54 ms
  • only ~14 ms is “actual application”
  • most is CLI overhead; native AOT targets that overhead

Ecosystem motivation:

  • making the CLI work with AOT/trim requires fixing dependencies (e.g., templating, NuGet, parts of MSBuild) to be trim friendly

Telemetry/observability:

  • native CLI emits OpenTelemetry (OTEL) so Aspire dashboard can trace native vs managed spans

Targeting which commands to move:

  • prioritize frequently used and dependency-free-ish commands (examples: solution management; also template/tooling related)
  • possibility of future native AOT for commands like dotnet new-related commands

4) MSBuild multithreading direction

  • MSBuild in .NET 11 moves toward embracing threads (not only multiprocess)
  • current multiprocess isolation is safe but has overheads:
    • IPC cost
    • CLR loading costs
  • multithreaded mode is not ready today, but expected by the time .NET 11 launches

Reference mentioned for task authors:

  • hackam/msbuildmasks

5) Tool acquisition improvements

A. Native AOT tool for managing toolchains: “dotnet UP” (NetUP)

  • native AOT tool intended to standardize installing/managing .NET toolchains across platforms
  • supports nightlies and global.json behavior
  • uses user-level installs (no admin required)
  • previews expected soon; a separate deep dive recording exists

B. Reducing SDK download size for containers

  • SDK tarballs/packages now use hard-link-based deduplication during packaging
  • impact:
    • reduced on-disk SDK payload size by about ~80 MB across platforms (preview cumulative result cited)
  • motivation:
    • faster download/arrival and less network IO, especially for SDK containers

Runtime and libraries improvements (runtime + library APIs)

Rich Lander: process API safety & convenience upgrades (Preview 4)

They discuss improvements to the process API, used to start processes and capture output.

Problem highlighted

Certain stdout/stderr capture patterns can deadlock when capturing both stdout and stderr with full diagnostics:

  • code reads stdout to end first
  • stderr buffer fills
  • writer blocks
  • stdout read waits indefinitely

New convenience APIs

APIs added to “run and capture” and “stream” results correctly:

  • Run and capture text async: returns stdout, stderr, exit codes
  • Read all lines async: streams lines and indicates whether each line is stderr
  • Create anonymous pipe API: enables safe pipeline-style composition (C# equivalent of cmd | othercmd)

Fire-and-forget process support

  • start process without collecting results
  • nuance: process can be killed on parent exit depending on the use case

SafeProcessHandle

  • introduced to address trimming/security concerns
  • described as a safer type than the normal process handle
  • “said to trim better”

Text processing & Unicode conformance

  • New UTF validation APIs:
    • is-valid (for UTF8/UTF16)
    • index-of-invalid-subsequence (returns where the invalid sequence begins)
  • New newline handling:
    • “any new line” regex-like capability to handle newline variants beyond just \r\n
  • Rune-aware string methods:
    • updates ensure operations treat Unicode code points correctly
    • relevant for emojis/multi-code-unit characters
    • includes an example for parsing GitHub comments containing emojis

System.Text.Json policy flexibility

Enhancements support agent-like policy-driven serialization, including:

  • type-level rule: don’t emit properties when null
  • global naming strategy (e.g., PascalCase)
  • per-property override (e.g., event name serialized as camelCase)

Also included:

  • JSON Lines / NDJSON writing
    • async producing multiple JSON documents per line
    • opt-in via a top-level option (e.g., “values=true” noted)

Compression improvements

  • Zstandard integration into the product’s compression APIs
  • improvements across multiple algorithms
  • Zstandard highlighted as highly competitive in compression results (example mentions compressing runtime repo text with “optimal” vs “smallest size” settings)

Runtime projects: big internal technology changes

1) Runtime async (opt-in in .NET 11)

They introduce Runtime async as a performance optimization for async, without requiring source changes:

  • enabled via compile-time feature flag (runtime-async=on)
  • compatibility:
    • new/old code can interoperate
    • no breaking changes implied

Core concept:

  • removes generation/use of compiler-made async state machines
  • replaces with runtime-managed mechanisms

Claimed benefits:

  • cleaner stack frames (diagnostics)
  • reduced binary size (state machine removal)
  • potential performance improvements
  • future runtime optimizations can improve code without recompiling libraries

Demo description:

  • in .NET 10, stack traces include state machine frames
  • in .NET 11 with runtime async enabled, those frames disappear while stack correctness remains

2) Memory safety (Net 11/12 roadmap)

They describe a multi-release initiative:

  • .NET 11: define language changes and apply them to system-private corlib; reduce unsafe usage requirements
  • .NET 12: finish the work

Key principle:

  • redesign unsafe as a reviewable caller contract rather than a broad “unsafe context”
  • related APIs like unsafe and MemoryMarshal are marked accordingly

Performance work tied to this:

  • improvements for bounds-check elimination and inlining, including:
    • better reasoning about span bounds to avoid extra checks
    • improvements enabling safer tail-slice patterns
    • better inlining reducing null checks/throw paths

SIMD + memory safety:

  • goal: reduce unsafe usage by improving JIT correctness so SIMD-related unsafe patterns can become safe and more optimizable

Feedback & adoption guidance

  • Encourage installing .NET 11 previews and providing feedback via:
    • GitHub issues/discussions
    • blog posts
  • They emphasize that early hands-on feedback improves GA readiness.
  • For features shipping in .NET 12, feedback is also encouraged.

Main speakers / sources

  • Chad Husk — Product Manager, SDK and MSBuild teams (Microsoft)
  • Rich Lander — Product Manager on the .NET team (Microsoft)

Original video