Freigeben über

Erste Schritte mit .NET Native

  • Artikel

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 Sie eine Universelle Windows-Plattform-App (UWP), und testen Sie die Debugbuilds Ihrer App, um sicherzustellen, dass sie ordnungsgemäß funktioniert.

  2. Behandeln Sie zusätzliche Verwendungen von Reflektion und Serialisierung.

  3. Deploy and test the release builds of your app (Stellen Sie die Releasebuilds Ihrer App bereit, und testen Sie sie).

  4. Manually resolve missing metadata (Beheben Sie fehlende Metadaten manuell), und wiederholen Sie Schritt 3, bis alle Probleme gelöst sind.

Hinweis

Wenn Sie eine vorhandene Windows 8.x-App zu .NET Native migrieren, lesen Sie die Migration Ihrer Windows 8.x-App zu .NET Native.

Schritt 1: Entwickeln und Testen von Debugbuilds der UWP-App

Egal, ob Sie eine neue App entwickeln oder eine vorhandene migrieren, Sie verwenden immer dasselbe Verfahren 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 sind alle UWP-Apps auf CoreCLR ausgerichtet und ihre Releasebuilds werden mithilfe der .NET Native-Toolkette kompiliert.

  2. Beachten Sie, dass es einige bekannte Kompatibilitätsprobleme zwischen dem Kompilieren von UWP-App-Projekten mit und ohne .NET Native-Toolkette gibt. 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.

Wichtig

Beachten Sie bei der Entwicklung Ihrer App jede Verwendung von Serialisierung oder Reflektion im Code.

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

Schritt 2: Behandeln zusätzlicher Verwendungen von Reflektion und Serialisierung

Eine Laufzeitdirektivendatei, "Default.rd.xml", die beim Erstellen automatisch Ihrem Projekt hinzugefügt wird. Wenn Sie in C# entwickeln, finden Sie die Datei im Eigenschaften -Ordner Ihres Projekts. Wenn Sie in Visual Basic entwickeln, finden Sie die Datei im Mein Projekt -Ordner Ihres Projekts.

Hinweis

Eine Übersicht über den .NET Native-Kompilierungsprozess mit Hintergrundinformationen, die verdeutlichen, warum eine Laufzeitdirektivendatei erforderlich ist, finden Sie unter .NET Native und Kompilierung.

Die Laufzeitdirektivendatei wird verwendet, um die von Ihrer App zur Laufzeit benötigten Metadaten zu definieren. In einigen Fällen sollte diese Standardversion der Datei ausreichend sein. Code, der die Serialisierung oder Reflektion nutzt, kann jedoch zusätzliche Einträge in der Laufzeitdirektivendatei erfordern.

Serialisierung

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

  • Nicht reflektionsbasierte Serialisierungsprogramme. Die Serialisierungsprogramme in der .NET Framework-Klassenbibliothek, wie die Klassen DataContractSerializer, DataContractJsonSerializerund XmlSerializer , beruhen nicht auf Reflektion. Sie erfordern jedoch, dass Code basierend auf dem Objekt generiert wird, das serialisiert oder deserialisiert werden soll. Weitere Informationen finden Sie im Abschnitt zu Serialisierungsprogrammen von Microsoft unter Serialization and Metadata.

  • Serialisierungsprogramme von Drittanbietern. Serialisierungsbibliotheken von Drittanbietern, von denen die verbreitetste das Newtonsoft JSON-Serialisierungsprogramm ist, basieren im Allgemeinen auf Reflektion und benötigen Einträge in der Datei *.rd.xml, um Objektserialisierung und Deserialisierung zu unterstützen. Weitere Informationen finden Sie im Abschnitt „Serialisierungsprogramme von Drittanbietern“ unter Serialization and Metadata.

Auf Reflektion beruhende Methoden

In einigen Fällen ist die Verwendung von Reflektion im Code nicht offensichtlich. Einige gängige APIs oder Programmiermuster gelten nicht als Teil der Reflektions-API, aber benötigen die Reflektion, um erfolgreich ausgeführt zu werden. Dazu zählen die folgenden Methoden zur Typinstanziierung und Methodenkonstruktion:

Weitere Informationen finden Sie unter APIs That Rely on Reflection.

Hinweis

In Laufzeitdirektivendateien verwendete Typnamen müssen vollqualifiziert sein. Beispielsweise muss in der Datei "System.String" anstelle von "String" angegeben sein.

Schritt 3: Bereitstellen und Testen der Releasebuilds Ihrer App

Nachdem Sie die Laufzeitdirektivendatei aktualisiert haben, können Sie Releasebuilds Ihrer App neu erstellen und bereitstellen. .NET Native Binärdateien werden im Unterverzeichnis "ILC.out" des Verzeichnisses platziert, das im Textfeld "Ausgabepfad erstellen" des Dialogfelds "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, auch Ausfallszenarien, für sämtliche Zielplattformen.

Wenn Ihre App nicht ordnungsgemäß funktioniert (insbesondere in Fällen, in denen fehlendeMetadataException- oder MissingInteropDataException-Ausnahmen zur Laufzeit ausgelöst werden), befolgen Sie die Anweisungen im nächsten Abschnitt, Schritt 4: Manuelles Auflösen fehlender Metadaten. Das Aktivieren von Ausnahmen der ersten Chance kann hilfreich sein, um diese Fehler zu finden.

Wenn Sie die Debugbuilds Ihrer App getestet und gedebuggt haben und sicher sind, dass Sie die Ausnahmen "MissingMetadataException " und "MissingInteropDataException " eliminiert haben, sollten Sie Ihre App als optimierte .NET Native-App testen. Zu diesem Zweck ändern Sie die aktive Projektkonfiguration von Debug in Release.

Schritt 4: Manuelles Beheben fehlender Metadaten

Der häufigste Fehler, der bei .NET Native auftritt, der auf dem Desktop nicht auftritt, ist die Laufzeit MissingMetadataException, MissingInteropDataException oder MissingRuntimeArtifactException. In einigen Fällen kann das Fehlen von Metadaten zu unvorhersehbarem Verhalten oder sogar zu App-Fehlern führen. Dieser Abschnitt beschreibt, wie Sie diese Ausnahmen debuggen und beheben können, indem Sie Direktiven zur Laufzeitdirektivendatei hinzufügen. Informationen zu Laufzeitanweisungen finden Sie unter Runtime Directives (rd.xml) Configuration File Reference (Verweis auf die Konfigurationsdatei von Laufzeitanweisungen (rd.xml)). Nachdem Sie Laufzeitdirektiven hinzugefügt haben, sollten Sie Ihre App erneut bereitstellen und testen und alle neuen MissingMetadataException-, MissingInteropDataException- und MissingRuntimeArtifactException-Ausnahmen auflösen, bis keine weiteren Ausnahmen auftreten.

Tipp

Geben Sie die Laufzeitdirektiven auf einer hohen Ebene an, um Ihre App flexibel in Bezug auf Codeänderungen zu machen. Es wird empfohlen, Laufzeitdirektiven auf Namespace- und Typebene statt auf Memberebene hinzufügen. Beachten Sie, dass möglicherweise ein Kompromiss zwischen Flexibilität und größeren Binärdateien mit längeren Kompilierungszeiten gefunden werden muss.

Beim Behandeln einer Ausnahme wegen fehlender Metadaten sollten Sie Folgendes berücksichtigen:

  • Was versuchte die App vor der Ausnahme auszuführen?

    • Versuchte sie beispielsweise Daten zu binden, zu serialisieren oder zu deserialisieren oder direkt die Reflektions-API zu verwenden?

  • Ist dies ein Einzelfall, oder glauben Sie, dass das gleiche Problem für andere Typen auftreten wird?

    • Beispielsweise wird beim Serialisieren eines Typs im Objektmodell der App eine MissingMetadataException-Ausnahme ausgelöst. Wenn Sie andere Typen kennen, die serialisiert werden, können Sie gleichzeitig Laufzeitdirektiven für diese Typen hinzufügen (oder für deren enthaltende Namespaces, je nachdem, wie gut der Code strukturiert ist).

  • Können Sie den Code neu schreiben, damit er keine Spiegelung verwendet?

    • Verwendet der Code zum Beispiel das Schlüsselwort dynamic , wenn Sie wissen, welcher Typ zu erwarten ist?

    • Ruft der Code eine Methode auf, die von Reflektion abhängt, wenn eine bessere Alternative zur Verfügung steht?

Hinweis

Weitere Informationen zur Behandlung von Problemen, die sich aus unterschiedlichen Spiegelungsunterschieden 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 das Behandeln von Ausnahmen und anderen Problemen beim Testen der App finden Sie unter:

Weitere Informationen