Laufzeitausnahmen in .NET Native-Apps
Es ist wichtig, die Releasebuilds Ihrer App für die universelle Windows-Plattform auf den Zielplattformen zu testen, da die Debug- und Releasekonfigurationen völlig unterschiedlich sind. Die Debugkonfiguration verwendet standardmäßig die .NET Core-Laufzeit zum Kompilieren der App, während die Releasekonfiguration .NET Native verwendet, um die App in systemeigenen Code zu kompilieren.
Wichtig
Informationen zum Umgang mit den Ausnahmen MissingMetadataException, MissingInteropDataException und MissingRuntimeArtifactException, die möglicherweise beim Testen der Releaseversionen Ihrer App auftreten, finden Sie im Thema Erste Schritte unter „Schritt 4: Manuelles Beheben fehlender Metadaten“ sowie unter Reflektion und .NET Native und Runtime Directives (rd.xml) Configuration File Reference (Verweis auf die Konfigurationsdatei der Laufzeitanweisungen (rd.xml)).
Debugbuilds und Releasebuilds
Wenn der Debugbuild unter Verwendung der .NET Core-Laufzeit ausgeführt wird, wurde er nicht in systemeigenen Code kompiliert. Dadurch werden alle Dienste, die normalerweise von der Laufzeit bereitgestellt werden, für Ihre App verfügbar.
Andererseits werden der Releasebuild für die Zielplattformen in systemeigenen Code kompiliert, die meisten Abhängigkeiten von externen Laufzeiten und Bibliotheken entfernt und Code für maximale Leistung optimiert.
Beim Debuggen von Releasebuilds, die mithilfe von .NET Native kompiliert wurden, geschieht Folgendes:
Sie verwenden die .NET Native-Debug-Engine, die sich von den normalen .NET-Debugtools unterscheidet.
Die Größe Ihrer ausführbaren Datei wird so weit wie möglich reduziert. Eine der Methoden, durch die .NET Native die Größe einer ausführbaren Datei verringert, besteht darin, dass Laufzeitausnahmemeldungen erheblich gekürzt werden. Dieses Thema wird ausführlicher im Abschnitt Runtime exception messages erörtert.
Der Code wird stark optimiert. Dies bedeutet, dass nach Möglichkeit Inlining 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 Runtime call stack .
Hinweis
Sie können steuern, ob die Debug- und Releasebuilds mit der .NET Native-Toolkette kompiliert werden, indem Sie das Kontrollkästchen Mit .NET Native-Toolkette kompilieren aktivieren oder deaktivieren. Microsoft Store kompiliert jedoch immer die Produktionsversion Ihrer App mit der .NET Native-Toolkette.
Runtime exception messages
Um die Größe ausführbarer Anwendungsdateien zu minimieren, schließt .NET Native nicht den vollständigen Text von Ausnahmemeldungen ein. Daher wird bei Laufzeitausnahmen, die in Releasebuilds ausgelöst werden, u. U. nicht der vollständige Text der Ausnahmemeldungen angezeigt. Stattdessen kann der Text eine Teilzeichenfolge und einen Link umfassen, über den weitere Informationen abgerufen werden können. Beispielsweise können Ausnahmeinformationen wie folgt angezeigt werden:
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 Debugbuild aus. Beispielsweise könnte die vorherigen Ausnahmeinformationen aus dem Releasebuild im Debugbuild wie folgt aussehen:
Exception thrown: 'System.AggregateException' in NativeApp.exe.
Additional information: Value does not fall within the expected range.
Runtime call stack
Durch das Inlining und andere Optimierungen kann es schwierig sein, den Pfad zu einer Laufzeitausnahme anhand der Aufrufliste, die von einer App angezeigt wird, die von der .NET Native-Toolkette kompiliert wurde, eindeutig zu identifizieren.
Um die vollständige Aufrufliste zu erhalten, führen Sie stattdessen den Debugbuild aus.