Freigeben über


Erste Schritte mit .NET Native

Von Bedeutung

Modernisieren Sie Ihre UWP-App mit .NET und nativen AOT: Wenn Sie eine neue UWP-App entwickeln oder eine vorhandene UWP-App modernisieren möchten, empfehlen wir die Verwendung UWP-Unterstützung für die neuesten .NET mit Native AOT anstelle von .NET Native. UWP-Unterstützung für moderne .NET ist jetzt allgemein verfügbar und ist der default-Projekttyp für C#-UWP-Apps in Visual Studio 2026. Dadurch erhalten Sie Zugriff auf die neuesten .NET- und C#-Features, verbesserte Tool- und Debuggingunterstützung und schnellere Buildzeiten. .NET Native erhält weiterhin Sicherheits- und Zuverlässigkeitsfixes, erhält aber keine neuen Funktionsupdates.

Ganz gleich, ob Sie eine neue UWP-App schreiben oder eine vorhandene Windows 8.x-App migrieren (zuvor auch als Microsoft Store-App bezeichnet), können Sie den gleichen Satz von Verfahren befolgen. Führen Sie die folgenden Schritte aus, um eine .NET native App zu erstellen:

  1. Entwickeln Sie eine Universelle Windows-Plattform (UWP)-App, und testen Sie die Debugbuilds Ihrer App, um sicherzustellen, dass sie ordnungsgemäß funktioniert.

  2. Behandlung zusätzlicher Nutzung von Reflexion und Serialisierung.

  3. Bereitstellen und Testen der Release-Builds Ihrer App.

  4. Manuelles Beheben fehlender Metadaten, und wiederholen Sie Schritt 3, bis alle Probleme behoben werden.

Hinweis

Wenn Sie eine vorhandene Windows 8.x-App zu .NET Native migrieren, überprüfen Sie unbedingt Migrating Your Windows 8.x App to .NET Native.

Schritt 1: Entwickeln und Testen von Debug-Builds Ihrer UWP-App

Unabhängig davon, ob Sie eine neue App entwickeln oder eine vorhandene App migrieren, folgen Sie demselben Prozess wie für jede Windows-App.

  1. Erstellen Sie ein neues UWP-Projekt in Visual Studio mithilfe der Vorlage "Universelle Windows-App" für Visual C# oder Visual Basic. Standardmäßig werden alle UWP-Anwendungen auf coreCLR ausgerichtet, und ihre Releasebuilds werden mithilfe der .NET nativen Toolkette kompiliert.

  2. Beachten Sie, dass es einige bekannte Kompatibilitätsprobleme zwischen der Kompilierung von UWP-App-Projekten mit der .NET Native-Toolkette und ohne diese gibt. Weitere Informationen finden Sie im Migrationshandbuch.

Sie können jetzt C# oder Visual Basic Code für den .NET nativen Oberflächenbereich schreiben, der auf dem lokalen System (oder im Simulator) ausgeführt wird.

Von Bedeutung

Beachten Sie beim Entwickeln Ihrer App jede Verwendung von Serialisierung oder Reflection in Ihrem Code.

Standardmäßig werden Debugbuilds JIT-kompiliert, um eine schnelle F5-Bereitstellung zu ermöglichen, während Releasebuilds mithilfe der .NET Native Pre-Compilation-Technologie kompiliert werden. Dies bedeutet, dass Sie die Debugbuilds Ihrer App erstellen und testen sollten, um sicherzustellen, dass sie normal funktionieren, bevor sie mit der .NET nativen Toolkette kompiliert werden.

Schritt 2: Umgang mit zusätzlicher Reflexions- und Serialisierungsverwendung

Beim Erstellen wird dem Projekt automatisch eine Laufzeitdirektivendatei Default.rd.xmlhinzugefügt. Wenn Sie in C# entwickeln, befindet es sich im ordner Eigenschaften Ihres Projekts. Wenn Sie in Visual Basic programmieren, befindet es sich im Ordner My Project Ihres Projekts.

Hinweis

Eine Übersicht über den .NET nativen Kompilierungsprozess, der Hintergrund darüber bereitstellt, warum eine Laufzeitdirektivendatei erforderlich ist, finden Sie unter .NET Native und Compilation.

Die Datei mit Laufzeitanweisungen wird verwendet, um die Metadaten zu definieren, die Ihre App zur Laufzeit benötigt. In einigen Fällen ist die Standardversion der Datei möglicherweise ausreichend. Einiger Code, der auf Serialisierung oder Reflektion basiert, erfordert jedoch möglicherweise zusätzliche Einträge in der Laufzeitdirektivendatei.

Serialisierung

Es gibt zwei Kategorien von Serialisierern, und beide erfordern möglicherweise zusätzliche Einträge in der Laufzeitdirektivendatei:

  • Nicht spiegelungsbasierte Serialisierer. Die Serialisierer in der klassenbibliothek .NET Framework, z. B. DataContractSerializer, DataContractJsonSerializer und XmlSerializer Klassen, basieren nicht auf Spiegelung. Es ist jedoch erforderlich, dass der Code basierend auf dem Objekt generiert wird, das serialisiert oder deserialisiert werden soll. Weitere Informationen finden Sie im Abschnitt "Microsoft Serializer" in Serialization and Metadata.

  • Serialisierer von Drittanbietern. Serialisierungsbibliotheken von Drittanbietern, von denen die am häufigsten verwendete der Newtonsoft JSON-Serialisierer ist, sind im Allgemeinen reflektionsbasiert und erfordern Einträge in der Datei *.rd.xml, um die Objektserialisierung und -deserialisierung zu unterstützen. Weitere Informationen finden Sie im Abschnitt "Serializer von Drittanbietern" in Serialisierung und Metadaten.

Methoden, die auf Reflexion beruhen

In einigen Fällen ist die Verwendung der Spiegelung im Code nicht offensichtlich. Einige gängige APIs oder Programmiermuster werden nicht als Teil der Reflexions-API angesehen, sondern verlassen sich auf Reflexion, um erfolgreich ausgeführt zu werden. Dazu gehören die folgenden Methoden der Typ-Instanziierung und der Methodenkonstruktion:

Weitere Informationen finden Sie unter APIs, die auf Reflectionbasieren.

Hinweis

Typennamen, die in Laufzeitdirektivendateien verwendet werden, müssen vollständig qualifiziert sein. Die Datei muss z. B. "System.String" anstelle von "String" angeben.

Schritt 3: Bereitstellen und Testen der Releasebuilds Ihrer App

Nachdem Sie die Laufzeitdirektivendatei aktualisiert haben, können Sie Release-Builds Ihrer App neu erstellen und bereitstellen. .NET Native Binärdateien werden im Unterverzeichnis "ILC.out" des Verzeichnisses platziert, das im Textfeld Build-Ausgabepfad des Dialogfelds Properties auf der Registerkarte Compile angegeben ist. Binärdateien, die sich nicht in diesem Ordner befinden, wurden nicht mit .NET Native kompiliert. Testen Sie Ihre App gründlich, und testen Sie alle Szenarien, einschließlich Fehlerszenarien, auf den einzelnen Zielplattformen.

Wenn Ihre App nicht ordnungsgemäß funktioniert (insbesondere in Fällen, in denen sie MissingMetadataException oder MissingInteropDataException Ausnahmen während der Ausführung auslöst), folgen Sie den Anweisungen im nächsten Abschnitt Schritt 4: Manuelles Auflösen fehlender Metadaten. Das Aktivieren von First-Chance-Ausnahmen kann Ihnen helfen, diese Fehler zu finden.

Wenn Sie die Debugbuilds Ihrer App getestet und Fehler behoben haben und sicher sind, dass Sie die MissingMetadataException und MissingInteropDataException beseitigt haben, sollten Sie Ihre App als optimierte .NET Native-App testen. Ändern Sie dazu die aktive Projektkonfiguration von Debug- in Release-.

Schritt 4: Manuelles Auflösen fehlender Metadaten

Der häufigste Fehler, der bei .NET Native und nicht auf dem Desktop auftritt, ist eine Laufzeit MissingMetadataException, MissingInteropDataException oder MissingRuntimeArtifactException Ausnahme. In einigen Fällen kann sich das Fehlen von Metadaten im unvorhersehbaren Verhalten oder sogar bei App-Fehlern manifestieren. In diesem Abschnitt wird erklärt, wie Sie diese Ausnahmen debuggen und beheben können, indem Sie der Laufzeitdatei Direktiven hinzufügen. Informationen zum Format der Laufzeitdirektiven finden Sie unter Runtime-Direktiven (rd.xml) Konfigurationsdateireferenz. Nachdem Sie Laufzeitdirektiven hinzugefügt haben, sollten Sie Ihre App erneut bereitstellen und testen und alle neuen MissingMetadataException, MissingInteropDataException und MissingRuntimeArtifactException Ausnahmen beheben, bis keine weiteren Ausnahmen auftreten.

Tipp

Geben Sie die Laufzeitdirektiven auf hoher Ebene an, damit Ihre App für Codeänderungen widerstandsfähig ist. Es wird empfohlen, Laufzeitdirektiven auf Namespace- und Typebene anstelle der Memberebene hinzuzufügen. Beachten Sie, dass es möglicherweise einen Kompromiss zwischen Resilienz und größeren Binärdateien mit längeren Kompilierungszeiten gibt.

Berücksichtigen Sie beim Umgang mit einer fehlenden Metadaten-Ausnahme die folgenden Probleme:

  • Was hat die App vor der Ausnahme zu machen versucht?

    • War es zum Beispiel Datenbindung, Serialisierung oder Deserialisierung von Daten oder die direkte Nutzung der Reflection-API?
  • Ist dies ein isolierter Fall, oder glauben Sie, dass das gleiche Problem für andere Typen auftritt?

    • Beispielsweise wird eine MissingMetadataException Ausnahme ausgelöst, wenn ein Typ im Objektmodell der App serialisiert wird. Wenn Sie andere Typen kennen, die serialisiert werden sollen, können Sie Laufzeitdirektiven für diese Typen (oder für deren enthaltende Namespaces, je nachdem, wie gut der Code organisiert ist) gleichzeitig hinzufügen.
  • Können Sie den Code neu schreiben, damit er keine Spiegelung verwendet?

    • Verwendet der Code beispielsweise das schlüsselwort dynamic, wenn Sie wissen, welcher Typ erwartet werden soll?

    • Ruft der Code eine Methode auf, die von Reflexion abhängt, wenn eine bessere Alternative verfügbar ist?

Hinweis

Weitere Informationen zur Behandlung von Problemen, die sich aus unterschiedlichen Spiegelungen und der Verfügbarkeit von Metadaten in Desktop-Apps und .NET Native ergeben, finden Sie unter APIs, die auf Spiegelung basieren.

Einige spezifische Beispiele für die Behandlung von Ausnahmen und anderen Problemen, die beim Testen ihrer App auftreten, finden Sie unter:

Siehe auch