Erklärung des Begriffs: Native AOT (NAOT)

In .NET 7.0

• nur für Konsolenanwendungen
• Keine Laufzeitcodegenerierung (Reflection.Emit)
• Kein Entity Framework Core, Dapper, AutoMapper -> nur ADO.NET und NanORM https://github.com/DamianEdwards/Nanorm
• Keine Kompilierung von Expressions
• Kein dynamisches Nachladen von Assemblies (Add-Ins/Plug-Ins) mit Assembly.LoadFile()
• Keine COM-Interop, WinRT-APIs, WMI, ADS
• Kein C++/CLI
• Keine Dymamic PGO und andere Plattformoptimierungen

In .NET 8.0

• Auch für Minimal WebAPI, gRPC und Worker Services
• Weiterhin o.g. Einschränkungen

Native AOT aktivieren

• Mit <PublishAot>true</PublishAot> in der Projektdatei
• Seit .NET 8.0 mit --aot beim Anlegen eines Projekts bzw. per Projektvorlage in Visual Studio:

Weitere Hinweise zu Native AOT

• Optimierungsziele vom Entwickler konfigurierbar (Size | Speed), z.B. <IlcOptimizationPreference>Speed</IlcOptimizationPreference>
• Das Kompilieren mit Native AOT dauert deutlich länger und funktioniert bisher nur mit Konsolenprojekten.
• Native AOT verwendet Tree Shaking (Application Trimming)
• Das Ergebnis ist eine einzige ausführbare Datei, die alle notwendigen Teile der .NET-Laufzeitumgebung enthält (self-contained, single File).
• Es gibt darin weiterhin eine Runtime mit Garbage Collector, aber keinen Just-in-Timer-Compiler
• Die Ausführbare Datei ist spezifische für ein Betriebssystem und eine Prozessorarchitektur (z.B. win-x86 oder linux-x64)
• Erfordert zusätzliche Build-Werkzeuge

• Cross-Platform-Publishing ist nicht möglich
• Vor .NET 7.0 gab es in .NET nur AOT-Kompilierung für Blazor WebAssembly nach WebAssembly-Bytecode (seit .NET 6.0) und die in .NET Core 3.0 eingeführte CrossGen-Technik, bei der eine Assembly partiell schon zur Entwicklungszeit vorkompiliert wird, aber dennoch den gesamte Intermediate Code mitliefert.