Freigeben über


Erste Schritte mit .NET Native

Unabhängig davon, ob Sie eine neue UWP-App schreiben oder eine vorhandene Windows 8.x-App (zuvor auch als Microsoft Store-App bezeichnet) migrieren, können Sie die gleichen Verfahren ausführen. Führen Sie die folgenden Schritte aus, um eine .NET Native-App zu erstellen:

  1. Entwickeln einer UWP-App (Universelle Windows-Plattform), und testen Sie die Debug-Builds 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, lesen Sie unbedingt Migrieren Ihrer Windows 8.x-App zu .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 für universelle Windows-Apps für Visual C# oder Visual Basic. Standardmäßig zielen alle UWP-Anwendungen auf CoreCLR ab, und ihre Releasebuilds werden mithilfe der .NET Native-Toolkette kompiliert.

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

Sie können jetzt C# oder Visual Basic-Code für den .NET Native-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 Debug-Builds JIT-kompiliert, um eine schnelle F5-Bereitstellung zu ermöglichen, während Release-Builds mithilfe der .NET Native-Vorabkompilierungstechnologie 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 Native-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 entwickeln, befindet es sich im Ordner "My Project".

Hinweis

Für eine Übersicht über den .NET Native-Kompilierungsprozess, der Hintergrundinformationen darüber liefert, weshalb eine Laufzeitdirektivendatei erforderlich ist, siehe .NET Native and 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, die in der .NET Framework-Klassenbibliothek enthalten sind, z. B. die DataContractSerializer, DataContractJsonSerializerund 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 Serializers" in Serialisierung und Metadaten-.

  • 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 "Buildausgabepfad" der Registerkarte "Kompilieren" im Dialogfeld "Eigenschaften" des Projekts 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 Debug-Builds Ihrer App getestet und Fehler behoben haben und sicher sind, dass Sie die Ausnahmen MissingMetadataException- und MissingInteropDataException- beseitigt haben, sollten Sie Ihre App als .NET Native-App in optimierter Form testen. Ändern Sie dazu die aktive Projektkonfiguration von Debug- in Release-.

Schritt 4: Manuelles Auflösen fehlender Metadaten

Der häufigste Fehler, dem Sie bei .NET Native begegnen und nicht auf dem Desktop, ist eine Laufzeit MissingMetadataException, MissingInteropDataExceptionoder 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 testen und alle neuen MissingMetadataException-, MissingInteropDataExceptionund MissingRuntimeArtifactException Ausnahmen auflösen, 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 Unterschieden in der Reflexion und der Verfügbarkeit von Metadaten in Desktop-Apps und .NET Native ergeben, finden Sie unter APIs, die Reflection verwenden.

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

Siehe auch