News

.NET 7 Preview 3 Is All About Native AOT

• By David Ramel
• 04/15/2022

The new .NET 7 Preview 3 showcases native ahead-of-time (AOT) compilation, a much-requested and long-awaited feature for .NET, with Microsoft even taking the time to explain what it is.

The .NET 7 dev team moved native AOT from experimental status to mainstream development in last month's Preview 2, noting it had yet to add first-class support in the dotnet SDK for publishing projects with Native AOT.

In the Preview 3 announcement, Jon Douglas, senior program manager, NuGet, provided an update on how native AOT promises to help build faster, lighter apps, while explaining what it is for those not familiar, noting that its main advantages affect:

• Startup time
• Memory usage
• Access to restricted platforms (where no just-in time (JIT) compilation is allowed)
• Smaller size on disk

Here's part of his "What is Native AOT?" description:

Ahead-of-time (AOT) compilation refers to an umbrella of technologies which generate code at application build time, instead of run-time. AOT is not new to .NET. Today we ship ReadyToRun for client and server scenarios, and Mono AOT for mobile and WASM. Native AOT brings full native pre-compilation to .NET desktop client and server scenarios. Native AOT is not replacing these existing technologies, rather it's offering a new set of capabilities that unlocks new form factors.

Existing AOT-compiled .NET assemblies contain platform-specific data structures and native code to frontload work typically done at runtime. Precompiling these artifacts saves time at startup (e.g. ReadyToRun), and enables access to no-JIT platforms (e.g. iOS). If precompiled artifacts are not present, .NET either falls back to JIT or interpretation (depending on the platform).

Native AOT is similar to .NET's existing AOT technologies, but it produces only native artifacts. In fact, the Native AOT runtime does not know how to read the .NET assembly file formats -- everything is platform-native. The executable file format parsing is fully handled by the underlying operating system.

Native AOT was an important consideration for many developers a couple years ago when a survey indicated its absence was holding back .NET adoption.

Native AOT is not for all projects, though, and Microsoft says in .NET 7 it will primarily help developers who build console apps or native libraries.

"Looking ahead, Native AOT compatibility will be improved over the next few versions of .NET, however there will always be reasons to prefer JIT for many scenarios. We will also add first-class support in the dotnet SDK for publishing projects with Native AOT," said Douglas, who also noted a couple improvements to the scheme in Preview 3.

Other enhancements in Preview 3 affect observability, startup times, codegen, GC regions and more.

It was native AOT, however, that further dominated reader discussion in various comments to the announcement post, with said discussion addressing the lack of its support in WPF and WinForms projects.

For example, one comment read:

My thoughts about NativeAOT are:

1. It's incredibly disappointing that it's not supported by WPF / Winforms (dunno about MAUI). That makes it only a console / library feature. That means I cannot use it in any of my larger applications but for those it only matters. I don't need startup improvement for tiny console projects.
2. The output size of a simple hello world is ridiculous (5mb). The same written in C++ or Pascal ends up with ~100kb. Unfortunately it has been rejected to improve that.

So thanks for that but the way its (not) implemented it's not really useful, for me at least.

In response, a Microsoft developer pointed to community efforts to further that goal:

We plan to look into expanding the scenarios where NativeAOT is a good fit over time. It's a function of time and resources. It is already possible to use WinForms with NativeAOT, but it requires some polish and won't be advertised as a supported scenario because of that. I suggest following a .NET community member who helped to make a lot of progress on this over the years: Andrey Kurdyumov -- https://twitter.com/Kurdiumov. Here's one of his articles where he made tweaks to various open source WinForms apps to make them compatible with NativeAOT in the form it is right now: https://codevision.medium.com/again-winforms-and-nativeaot-fd068425cc13. It can give you an idea where are we now.

Further clues about where the dev team is at now can be found in the NativeAOT in .NET 7 #61231 GitHub issue, which shows the initial work being checked off and what's remaining in the first phase (pictured above).