.NET 7 Preview 3 Is About Native AOT – Visual Studio Magazine


.NET 7 Preview 3 is about native AOT

The new .NET 7 Preview 3 introduces 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’s all about.

The .NET 7 development team upgraded native AOT from experimental to mainstream development in Preview 2 last month, noting that it has yet to add first-class support in the SDK. dotnet for publishing projects with native AOT.

In Preview 3 announcementJon Douglas, Senior Program Manager, NuGet, provided an update on how native AOT promises to help build faster, lighter applications, while explaining what it is for those who don’t are unfamiliar, noting that its main benefits affect:

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

Here is part of his “What is Native AOT?” the description:

Ahead build (AOT) refers to a set of technologies that generate code at application build time, rather than at run time. AOT is not new to .NET. Today we ship Ready to run 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 does not replace these existing technologies, but rather offers a new feature set that unlocks new form factors.

Existing AOT-compiled .NET assemblies contain platform-specific data structures and native code to preload work typically done at runtime. Precompiling these artifacts saves boot time (eg, ReadyToRun) and enables access to non-JIT platforms (eg, iOS). If the precompiled artifacts are not present, .NET reverts to JIT or interpretation (depending on the platform).

Native AOT is similar to existing .NET AOT technologies, but it only produces native artifacts. In fact, the native AOT runtime doesn’t know how to read .NET assembly file formats – everything is native to the platform. Executable file format parsing is handled entirely by the underlying operating system.

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

Is the lack of an officially supported native AOT option stopping you from using .NET more?
[Click on image for larger view.] “Does the lack of an officially supported native AOT option stop you from using .NET more?” (source: Microsoft).

Native AOT isn’t for all projects, however, and Microsoft says that in .NET 7 it will primarily help developers building console apps or native libraries.

“Looking forward, Native AOT compatibility will be improved in future releases of .NET, but there will still be reasons to prefer JIT for many scenarios. We will also be adding first-class support in the dotnet SDK for publishing projects with Native AOT,” said Douglas, who also noted some schema improvements in Preview 3.

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

However, it was the native AOT that still dominated readers’ discussion in various comments on the announcement post, said discussion addressing the lack of its support in WPF and WinForms projects.

For example, a comment said:

My thoughts on NativeAOT are:

  1. It’s incredibly disappointing that it’s not supported by WPF/Winforms (don’t know about MAUI). This makes it a console/library only feature. That means I can’t use it in any of my larger applications, but for those it only matters. I don’t need startup enhancement for small 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 was rejected to improve this.

So thanks for that, but the way it’s (un)implemented isn’t really helpful, at least for me.

In response, a Microsoft developer highlighted community efforts to achieve this goal:

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

NativeAOT Goals in .NET 7
[Click on image for larger view.] NativeAOT Goals in .NET 7 (source: Microsoft).

Further clues to the current status of the development team can be found in the NativeAOT in .NET 7 #61231 GitHub issue, which shows the initial work being checked out and what’s left in the first phase (pictured above).

About the Author

David Ramel is an editor and writer for Converge360.

Briana R. Cross