Share via

Laufzeitausnahmen in .NET Native-Apps

  • Artikel

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 beim Testen der Releaseversionen Ihrer App auftreten können, finden Sie unter Schritt 4: Manuelles Auflösen fehlender Metadaten im thema Erste Schritte sowie Reflektion und .NET Native und Referenz zu Laufzeitdirektiven (rd.xml) zur Konfigurationsdatei.

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 spezialisierte Runtime 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. Der 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önnen die vorherigen Ausnahmeinformationen aus dem Releasebuild wie folgt im Debugbuild angezeigt werden:

Exception thrown: 'System.AggregateException' in NativeApp.exe.

Additional information: Value does not fall within the expected range.

Runtime call stack

Aufgrund von Inlining und anderen Optimierungen hilft Ihnen der Aufrufstapel, der von einer App angezeigt wird, die von der .NET Native Toolkette kompiliert wird, möglicherweise nicht dabei, den Pfad zu einer Laufzeitausnahme eindeutig zu identifizieren.

Um die vollständige Aufrufliste zu erhalten, führen Sie stattdessen den Debugbuild aus.

Siehe auch