Native AOT in .NET 8

[agocke]

• Native AOT Trimming & Perf Improvements in .NET 8 #79003
• Native AOT Diagnostics in .NET 8 #79241
• Native AOT Testing Improvements #79316
• Native AOT CLI Experience Improvements in .NET 8 #79570
• Trimming Tools in .NET 8 #78671
• Move linker repo to runtime linker#3034

[ghost]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Unordered list of things that we'd like to add for NativeAOT:

• Improve trimming support for APIs needed by common service Apps
  • ASP.NET web API projects Developers can safely trim ASP.NET apps to reduce their deployment payloads aspnetcore#27384
  • Azure SDK - Marking libraries as IsTrimmable Azure/azure-sdk-for-net#24238
• Onboard more service-focused apps
  • YARP
• More platform support
  • Mac x64/ARM64
  • Musl compatibility
• Share more with the CLR
  • Interop
  • Reflection
• Roslyn AOT analyzer - Improve support for Analyzer AOT warnings linker#2495

Author:	agocke
Assignees:	-
Labels:	area-Meta, untriaged
Milestone:	-

[filipnavara]

Mac x64/ARM64

Done, CI enabled with #75421

[am11]

Musl compatibility

This works with .NET 7. We even have docs listing Alpine Linux prerequisites: https://github.com/dotnet/docs/blob/main/docs/core/deploying/native-aot/index.md#prerequisites.

note: in reality, we only need apk add build-base zlib-dev in addition to icu-libs in a fresh VM / container to PublishAot a fully loaded mvc app.. lld is especially not a prerequisite.

[jkotas]

note: in reality, we only need apk add build-base zlib-dev

Fixed in dotnet/docs#31535

[ygoe]

Are there plans to support the arm32 (armhf) architecture? This is relevant for most Raspberry Pi environments that are not using the newest 64-bit OS or older hardware (before RPi 3). Armbian also does not seem to offer 64-bit images yet (for other devices like NanoPi, Orange Pi etc.).

[MichalPetryka]

Are there plans to support the arm32 (armhf) architecture? This is relevant for most Raspberry Pi environments that are not using the newest 64-bit OS or older hardware (before RPi 3). Armbian also does not seem to offer 64-bit images yet (for other devices like NanoPi, Orange Pi etc.).

There are plans to remove ARM32 support from CoreCLR in .Net 9 (and NativeAOT uses that for codegen).

[MichalStrehovsky]

Are there plans to support the arm32 (armhf) architecture? This is relevant for most Raspberry Pi environments that are not using the newest 64-bit OS or older hardware (before RPi 3). Armbian also does not seem to offer 64-bit images yet (for other devices like NanoPi, Orange Pi etc.).

There are plans to remove ARM32 support from CoreCLR in .Net 9 (and NativeAOT uses that for codegen).

That said, we would still accept community contributions towards ARM32-Linux. It used to work at some point and it's probably not too far from working. No matter the resolution of the ARM32 .NET 9 discussion, for .NET 8 we'll still have all the infrastructure for Linux-ARM32 release and testing in place and we can run the port in the CI.

[agocke]

Also, as that issue mentions, that would be dropping Microsoft-maintained support. If community members would be willing to maintain support, that is up for discussion.

[ziaulhasanhamim]

I think till now the biggest performance problem with Native AOT is for reflection because ASP.NET CORE and EF Core-like frameworks are based on reflection. A nice possible way to solve many of these problems (not all) would be adding Rust-like macros in C#. Macros can do most of the important things that reflection does in compile time. In rust, all dynamic frameworks rely on it.

[DeafMan1983]

I should use musl-g++ with native aot if yes then I can continue with musl-libc for Alpine and Void-Linux.

[fishkapro]

Will com\wmi be added? Are there any ways to work with wmi now? Either the ability to use Microsoft.Management.Infrastructure or System.Management

[agocke]

.NET 8 is closing out, we'll pick new things up in .NET 9.