Freigeben über

Native AOT-Bereitstellung

Wenn Sie Ihre App als native AOT veröffentlichen, wird eine eigenständige App erzeugt, die vorab (AOT) in systemeigenem Code kompiliert wurde. Systemeigene AOT-Apps haben schnellere Startzeit und kleinere Speicherbedarfe. Diese Apps können auf Computern ausgeführt werden, auf denen die .NET-Laufzeit nicht installiert ist.

Der Vorteil nativer AOT ist für Workloads mit einer hohen Anzahl bereitgestellter Instanzen wie Cloudinfrastruktur und hyperskalierter Dienste am wichtigsten. .NET 8 fügt ASP.NET Core-Unterstützung für systemeigene AOT hinzu.

Das native AOT-Bereitstellungsmodell verwendet einen Vorabcompiler, um IL in nativen Code zu kompilieren, und zwar bereits bei der Veröffentlichung. Native AOT-Apps verwenden keinen Just-in-Time-Compiler (JIT), wenn die Anwendung ausgeführt wird. Native AOT-Apps können in eingeschränkten Umgebungen ausgeführt werden, in denen ein JIT nicht zulässig ist. Native AOT-Anwendungen zielen auf eine bestimmte Laufzeitumgebung wie Linux x64 oder Windows x64 ab, genau wie die Veröffentlichung einer eigenständigen App.

Voraussetzungen

Visual Studio 2022, einschließlich der Desktopentwicklung mit C++ -Workload mit allen Standardkomponenten.

Veröffentlichung von nativem AOT mithilfe der CLI

  1. Fügen Sie <PublishAot>true</PublishAot> Ihrer Projektdatei hinzu.

    Diese Eigenschaft ermöglicht die native AOT-Kompilierung während der Veröffentlichung. Es ermöglicht auch die dynamische Codeverwendungsanalyse während der Erstellung und Bearbeitung. Es ist vorzuziehen, diese Einstellung in die Projektdatei zu setzen, anstatt sie an die Befehlszeile zu übergeben, da sie verhalten außerhalb der Veröffentlichung steuert.

    <PropertyGroup>
    <PublishAot>true</PublishAot>
</PropertyGroup>

  2. Veröffentlichen Sie die Anwendung für eine bestimmte Laufzeitkennung mithilfe von dotnet publish -r <RID>.

    Im folgenden Beispiel wird die App für Windows als native AOT-Anwendung auf einem Computer veröffentlicht, auf dem die erforderlichen Voraussetzungen installiert sind.

    dotnet publish -r win-x64 -c Release

    Im folgenden Beispiel wird die App für Linux als native AOT-Anwendung veröffentlicht. Eine native AOT-Binärdatei, die auf Linux-Computern produziert wird, wird nur auf derselben oder neueren Linux-Version funktionieren. Eine native AOT-Binärdatei, die auf Ubuntu 20.04 erstellt wurde, wird auf Ubuntu 20.04 und späteren Versionen ausgeführt, aber sie wird nicht auf Ubuntu 18.04 ausgeführt.

    dotnet publish -r linux-arm64 -c Release

Die App ist im Veröffentlichungsverzeichnis verfügbar und enthält den gesamten Code, der für die Ausführung erforderlich ist, einschließlich einer stripped-down-Version der Coreclr-Laufzeit.

Schauen Sie sich die nativen AOT-Beispiele an, die im Dotnet/Samples-Repository auf GitHub verfügbar sind. Zu den Beispielen gehören Linux - und Windows Dockerfiles, die veranschaulichen, wie sie die Installation von Voraussetzungen automatisieren und .NET-Projekte mit Native AOT mithilfe von Containern veröffentlichen.

AOT-Kompatibilitätsanalysatoren

Die IsAotCompatible Eigenschaft wird verwendet, um anzugeben, ob eine Bibliothek mit Native AOT kompatibel ist. Erwägen Sie beispielsweise, dass eine Bibliothek die IsAotCompatible-Eigenschaft auf true setzt.

<PropertyGroup>
    <IsAotCompatible>true</IsAotCompatible>
</PropertyGroup>

Die vorangehende Konfiguration weist den folgenden Eigenschaften einen Standardwert true zu:

  • IsTrimmable
  • EnableTrimAnalyzer
  • EnableSingleFileAnalyzer
  • EnableAotAnalyzer

Diese Analysegeräte tragen dazu bei, sicherzustellen, dass eine Bibliothek mit nativem AOT kompatibel ist.

Systemeigene Debuginformationen

Standardmäßig erzeugt die native AOT-Veröffentlichung Debuginformationen in einer separaten Datei:

  • Linux: DBG
  • Windows: .pdb
  • macOS: DSYM-Ordner

Die Debugdatei ist erforderlich, um die App unter dem Debugger auszuführen oder Absturzabbilder zu prüfen. Setzen Sie auf Unix-ähnlichen Plattformen die StripSymbols Eigenschaft auf false, um die Debuginformationen in die native Binärdatei einzuschließen. Durch das Einschließen von Debuginformationen wird die systemeigene Binärdatei größer.

<PropertyGroup>
    <StripSymbols>false</StripSymbols>
</PropertyGroup>

Einschränkungen der nativen AOT-Bereitstellung

Systemeigene AOT-Apps haben die folgenden Einschränkungen:

  • Kein dynamisches Laden, z. B. Assembly.LoadFile.
  • Keine Laufzeitcodegenerierung, zum Beispiel System.Reflection.Emit.
  • Keine C++/CLI.
  • Windows: Keine integrierte COM.
  • Erfordert Kürzungen, die Einschränkungen aufweisen.
  • Impliziert die Kompilierung in einer einzelnen Datei, die bekannte Inkompatibilitäten aufweist.
  • Apps enthalten erforderliche Laufzeitbibliotheken (genau wie eigenständige Apps, die ihre Größe im Vergleich zu frameworkabhängigen Apps erhöhen).
  • System.Linq.Expressions verwenden immer die interpretierte Form, die langsamer als zur Laufzeit generierter kompilierter Code ist.
  • Generische Parameter, die durch Strukturtypargumente ersetzt werden, verfügen über speziellen Code, der für jede Instanziierung generiert wird. In der dynamischen Laufzeit werden viele Instanziierungen bei Bedarf generiert. In Native AOT werden alle Instanziierungen vorab generiert. Dies kann erhebliche Auswirkungen auf die Datenträgergröße der Anwendung haben. Generische virtuelle Methoden und generische Instanzmethoden werden auch für jeden Typ, der implementiert oder überschrieben wird, instanziiert.
  • Nicht alle Laufzeitbibliotheken sind vollständig als Native AOT-kompatibel markiert. Das heißt, einige Warnungen in den Laufzeitbibliotheken können von Endentwicklern nicht bearbeitet werden.
  • Diagnoseunterstützung für Debugging und Profilerstellung mit einigen Einschränkungen.
  • Unterstützung für einige ASP.NET Core-Features. Weitere Informationen finden Sie unter ASP.NET Core-Unterstützung für native AOT.

Der Veröffentlichungsprozess analysiert das gesamte Projekt und seine Abhängigkeiten auf mögliche Einschränkungen. Warnungen werden für jede Einschränkung ausgegeben, auf die die veröffentlichte App zur Laufzeit stoßen kann.

Einschränkungen für Plattform/Architektur

Die folgende Tabelle zeigt unterstützte Kompilierungsziele.

Plattform Unterstützte Architektur Hinweise
Fenster x64, Arm64
Linux (Englisch) x64, Arm64
macOS x64, Arm64
Ios ARM64 Experimentelle Unterstützung
iOSSimulator x64, Arm64 Experimentelle Unterstützung
tvOS ARM64 Experimentelle Unterstützung
tvOSSimulator x64, Arm64 Experimentelle Unterstützung
MacCatalyst x64, Arm64 Experimentelle Unterstützung
Android x64, Arm64 Experimental, keine integrierte Java-Interoperabilität

Weitere Informationen dazu, wie eine bestimmte Plattform von Native AOT unterstützt wird, finden Sie über den Link in der Tabelle.