Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Es ist wichtig, die Release-Builds Ihrer universellen Windows-Plattform-App auf ihren Zielplattformen zu testen, da die Debug- und Releasekonfigurationen völlig unterschiedlich sind. Standardmäßig verwendet die Debugkonfiguration die .NET Core-Laufzeit, um Ihre App zu kompilieren, die Releasekonfiguration verwendet jedoch .NET Native, um Ihre App in systemeigenem Code zu kompilieren.
Von Bedeutung
Informationen zum Umgang mit den MissingMetadataException, MissingInteropDataExceptionund MissingRuntimeArtifactException Ausnahmen, die beim Testen der Versionen Ihrer App auftreten können, finden Sie unter "Schritt 4: Manuelles Auflösen fehlender Metadaten" im Abschnitt Erste Schritte sowie unter Reflection und .NET Native und Runtime-Direktiven (rd.xml) Konfigurationsdateireferenz.
Debuggen und Freigeben von Builds
Wenn der Debugbuild gegen die .NET Core-Laufzeit ausgeführt wird, ist er nicht in nativen Code kompiliert worden. Dies macht alle Dienste, die üblicherweise von der Laufzeit bereitgestellt werden, für Ihre App verfügbar.
Andererseits kompiliert der Release-Build den nativen Code für seine Zielplattformen, entfernt die meisten Abhängigkeiten von externen Runtime-Umgebungen und Bibliotheken und optimiert den Code stark für maximale Leistung.
Beim Debuggen von Releasebuilds, die mithilfe von .NET Native kompiliert werden:
Sie verwenden das .NET Native-Debugmodul, das sich von den normalen .NET-Debugtools unterscheidet.
Die Größe Ihrer ausführbaren Datei wird so weit wie möglich reduziert. Eine der Möglichkeiten, wie .NET Native die Größe einer ausführbaren Datei reduziert, besteht darin, Laufzeit-Ausnahmemeldungen erheblich zu kürzen, ein Thema, das im Abschnitt mit Laufzeit-Ausnahmemeldungen ausführlicher erläutert wird.
Ihr Code ist stark optimiert. Dies bedeutet, dass die Inlinierung wann immer möglich verwendet wird. (Inlining verschiebt Code aus externen Routinen in die aufrufende Routine.) Die Tatsache, dass .NET Native eine spezielle Laufzeit bereitstellt und aggressives Inlining implementiert, wirkt sich auf den Aufrufstapel aus, der beim Debuggen angezeigt wird. Weitere Informationen finden Sie im Abschnitt zum Runtime-Aufrufstapel.
Hinweis
Sie können steuern, ob die Debug- und Releasebuilds mit der .NET Native-Toolkette kompiliert werden, indem Sie das Kompilieren mit .NET Native-Toolkette Kontrollkästchen aktivieren oder deaktivieren. Microsoft Store kompiliert jedoch immer die Produktionsversion Ihrer App mit der .NET Native-Toolkette.
Laufzeit-Ausnahmemeldungen
Um die ausführbare Größe der Anwendung zu minimieren, enthält .NET Native nicht den vollständigen Text von Ausnahmemeldungen. Daher werden in Releasebuilds ausgelöste Laufzeitausnahmen möglicherweise nicht den vollständigen Text von Ausnahmemeldungen anzeigen. Stattdessen kann der Text aus einer Teilzeichenfolge bestehen, ergänzt durch einen Link, der zu weiteren Informationen führt. Die Ausnahmeinformationen können z. B. wie folgt erscheinen:
Exception thrown: '$16_System.AggregateException' in Unknown Module.
Additional information: AggregateException_ctor_DefaultMessage
If there is a handler for this exception, the program may be safely continued.
Wenn Sie die vollständige Ausnahmemeldung benötigen, führen Sie stattdessen den Debug-Build aus. Die vorherigen Ausnahmeinformationen aus dem Releasebuild können z. B. wie folgt im Debugbuild angezeigt werden:
Exception thrown: 'System.AggregateException' in NativeApp.exe.
Additional information: Value does not fall within the expected range.
Laufzeitaufrufstapel
Aufgrund von Inlining und anderen Optimierungen kann der Aufrufstapel, der von einer App kompiliert mit der .NET Native-Toolkette erzeugt wird, möglicherweise nicht helfen, den Pfad zu einem Laufzeit-Fehler eindeutig zu identifizieren.
Um die vollständige Protokollkette abzurufen, führen Sie stattdessen den Debug-Build aus.