Enable .NET SDK Native-AOT Compilation

Summary

Transform the .NET SDK into a Native-AOT compiled application to significantly reduce startup time and improve performance for every single use of the dotnet CLI.

Motivation

The .NET CLI is one of the most frequently used developer tools in the .NET ecosystem. Currently, each CLI invocation incurs approximately ~150ms of startup overhead due to the managed runtime initialization process. While this may seem insignificant for individual commands, the aggregate impact is substantial:

• Developer productivity: The cumulative delay across daily workflows significantly impacts developer experience
• Global scale impact: With billions of monthly invocations, even small improvements translate to massive time savings
• Resource efficiency: Reduced memory footprint and faster startup times benefit both local development and cloud-based build environments

By converting the .NET SDK to Native-AOT, we can eliminate most of this startup overhead, providing near-instantaneous command execution and dramatically improving the developer experience at scale. We can also showcase and encourage the adoption of Native AOT for CLI applications, and make the dotnet CLI an example of a best-in-class .NET CLI application all-up.

Scope and Approach

This Epic encompasses the technical work required to enable Native-AOT compilation of the .NET SDK, including infrastructure changes, library updates, and runtime integration modifications. The work will be executed in phases, starting with AOT compatibility enablement and culminating in a hybrid architecture where AOT handles command parsing while managed code handles complex operations.

Technical Implementation Strategy

Phase 1: Enable AOT Compatibility Analysis

Goal: Enable IsAotCompatible MSBuild property across the SDK repository to identify all AOT-incompatible code paths.

• Enable <IsAotCompatible>true</IsAotCompatible> in Directory.Build.props
• Catalog and categorize all AOT warnings and errors
• Create tracking issues for each category of incompatibility

Phase 2: Resolve Core AOT Compatibility Issues

2.1 COM Interop Modernization

Problem: Current COM interop usage (e.g., DangerousFileDetector, VS workload manifest checking) uses reflection-based COM activation that's incompatible with AOT. There's a spike of what this might look like at #49669.

Solution: Migrate to source-generated COM interop

2.2 Telemetry Infrastructure Modernization

Problem: ApplicationInsights libraries are not AOT-compatible and never will be.

Solution: Migrate to OpenTelemetry + Azure Monitor OTel exporter - @MiYanni and I have this mostly working at #49409.

Tracking issue: #49668

2.3 JSON Handling Modernization

Problem: Dynamic JSON handling throughout the codebase needs to use System.Text.Json source generators for AOT compatibility.

Solution: Implement source-generated JSON serialization

NuGet Libraries: NuGet/Home#14408

Templating libraries: the template engine is built on top of Newtonsoft.Json - we need to migrate it to System.Text.Json and enable source generation by consumers.

• Enable trimming/AOTing in consuming applications templating#9193

SDK JSON Usage:

• Convert ToolManifestEditor.cs JSON handling to use source generators
• Update WorkloadManifestReader.cs to use source-generated JSON
• Migrate global.json parsing to AOT-compatible JSON handling
• Convert project template JSON processing to source generators
• Update workload manifest JSON processing

2.4 MSBuild Evaluation Infrastructure Changes

Problem: MSBuild evaluation requires pluggable, AOT-compatible infrastructure.

Solution: Create AOT-friendly MSBuild integration points

Tracking issue: dotnet/msbuild#12141

SdkResolver Infrastructure:

• Make MSBuild SdkResolver infrastructure pluggable to support static-friendly versions
  • SDK should implement statically-available version of SDK resolver that is used for any in-proc evaluation (any of the Project/ProjectInstance/ProjectCollection APIs
  • The existing managed resolvers also need to be maintained for out-of-proc builds and hosted editor scenarios)

Property Function Evaluation:

• Make MSBuild property function evaluation pluggable
  • Implement static-friendly property function evaluation
  • Update evaluation engine integration points for AOT compatibility
  • Ensure runtime property function evaluation remains available for complex scenarios
  • Ensure compatibility with MSBuild's built-in reflection-based functionality

2.5 Roslyn dependencies

The file-based apps feature set uses Roslyn APIs to do lexing, but those aren't AOT'd today. There's a WIP for enabling trimming over at dotnet/roslyn#66519 that would be a prerequisite here.

Phase 3: Runtime Integration

3.1 Muxer Integration

Goal: Modify the .NET Runtime muxer to invoke the AOT-compiled SDK when available.

• Collaborate with Runtime team to add SDK resolution check after SDK location but before CoreCLR initialization
• Implement fallback mechanism to managed SDK if AOT binary is unavailable
• Design handoff protocol between muxer and AOT SDK
• Ensure backward compatibility with existing SDK installations

3.2 Hybrid Architecture Implementation

Goal: Create a hybrid model where AOT handles command parsing and common operations, with managed code for complex scenarios.

Command Parsing Migration:

• Migrate all CLI command parsing to Native AOT
• Implement AOT-friendly argument parsing and validation
• Create command routing infrastructure in AOT

Command Handler Strategy:

• Implement pure-AOT handlers for simple commands (--version, --help, --info)
• Create managed invocation infrastructure for complex commands
• Design CoreCLR initialization and dotnet.dll loading for managed handlers
• Implement out-of-process MSBuild invocation for build commands

Phase 4: Incremental Command Migration

4.1 Pure-AOT Commands (Phase 4a)

Commands that do not use any of the above tech can be migrated to native handlers immediately.

• dotnet --version
• dotnet --info
• dotnet complete
• dotnet completions

4.3 Out-of-Process MSBuild Commands (Phase 4c)

Commands that perform MSBuild builds only (no evaluation) can be migrated to out-of-process MSBuild invocations immediately - note that file-based apps currently always must be handled by managed code, because they do build execution via the MSBuild API directly.

• dotnet build

4.2 Hybrid Commands (Phase 4b)

Commands that interact with NuGet/COM/MSBuild evaluation (which is most of them)
will need to wait until their associated blocker are migrated to AOT-compatible versions.

• dotnet new (template parsing and instantiation)
• dotnet package add/remove (NuGet operations)
• dotent tool management of all kinds
• dotnet workload management (install, update, list) of all kinds
• dotnet run
• dotnet test
• dotnet publish (uses one eval to determine if Release can be defaulted)
• dotnet pack

Partner Team Coordination

Dependencies on External Teams

.NET Runtime Team

• Muxer modification for AOT SDK invocation
  • Ensure compatibility with existing hosting models
  • Performance validation of new muxer behavior

NuGet Team

• NuGet library AOT compatibility
  • JSON serialization modernization
  • Some reflection usage that needs to be statically analyzable

MSBuild Team

• MSBuild API AOT compatibility
  • Property function evaluation infrastructure pluggability
  • SdkResolver service pluggability for

.NET Source-build Team

• OpenTelemetry library source-build integration

Success Metrics

Performance Targets

• Reduce cold start time by >80% (from ~150ms to <30ms)
• Maintain functional parity with managed SDK
• No/minor regression in command execution times for complex operations

Quality Gates

• All existing SDK functionality preserved
• Comprehensive test coverage for AOT scenarios
• Performance benchmarks validate improvements
• Backward compatibility maintained
• Gradual rollout with fallback mechanisms

Risks and Mitigations

Technical Risks

• AOT Limitations: Some dynamic scenarios may not be AOT-compatible
  • Mitigation: Hybrid architecture with managed fallback
• Performance Regression: Complex operations might be slower in AOT
  • Mitigation: Benchmark-driven development and selective AOT usage
• Compatibility Issues: Third-party integrations may break
  • Mitigation: Extensive compatibility testing and partner engagement

Delivery Risks

• Cross-team Dependencies: Multiple teams must coordinate delivery
  • Mitigation: Clear interface contracts and incremental integration
• Scope Creep: Additional AOT blockers discovered during implementation
  • Mitigation: Phased approach with continuous blocker assessment
  • Mitigation: Requirement to keep a managed fallback for all commands until AOT blockers are resolved