Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
L’AOT natif partage certaines fonctionnalités de diagnostic et d’instrumentation, mais pas toutes, avec le runtime .NET complet. Les applications compatibles avec la fonctionnalité Trim ne devraient pas présenter de différences de comportement. Par conséquent, les investigations s'appliquent souvent aux deux environnements d'exécution. Par conséquent, il est parfois approprié de diagnostiquer et de déboguer des problèmes dans le runtime .NET complet, car il dispose d’une vaste sélection d’utilitaires de diagnostic disponibles. Néanmoins, certaines informations ne peuvent être collectées qu’après la publication. C’est pour cela que l’AOT natif fournit également des outils de diagnostic post-publication.
Prise en charge native du diagnostic AOT
Le tableau ci-dessous récapitule les fonctionnalités de diagnostic prises en charge pour les déploiements AOT natifs :
| Fonctionnalité | Entièrement prise en charge | Partiellement prise en charge | Non pris en charge |
|---|---|---|---|
| Observabilité et télémétrie | Partiellement pris en charge | ||
| Diagnostics en phase de développement | Prise en charge intégrale | ||
| Débogage natif | Partiellement pris en charge | ||
| Profilage du processeur | Partiellement pris en charge | ||
| Analyse de tas | Non pris en charge |
Observabilité et télémétrie
À compter de .NET 8, le runtime AOT natif prend en charge EventPipe, qui est la couche de base utilisée par de nombreuses bibliothèques de journalisation et de suivi. Vous pouvez effectuer une interface avec EventPipe directement via des API telles que EventSource.WriteEvent ou des bibliothèques basées sur celles-ci, comme OpenTelemetry. La prise en charge d’EventPipe permet également aux outils de diagnostic .NET tels dotnet-trace, dotnet-counters et dotnet-monitor de fonctionner en toute transparence avec les applications natives AOT ou avec le runtime .NET complet. EventPipe est un composant facultatif dans AOT natif. Pour inclure la prise en charge d’EventPipe, définissez la propriété MSBuild EventSourceSupport sur true.
<PropertyGroup>
<EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>
Le mode AOT natif fournit une prise en charge partielle de certains fournisseurs d’événements connus. Les événements de runtime ne sont pas tous pris en charge dans AOT natif.
Diagnostics en phase de développement
Les outils CLI .NET (SDK dotnet) et Visual Studio offrent des commandes distinctes pour build et publish.
build (ou Start dans Visual Studio) utilise le runtime .NET complet. Seul publish crée une application AOT native. La publication de votre application en tant qu’application AOT native produit une application qui a été compilée à l’avance (AOT) en code natif. Comme mentionné antérieurement, les outils de diagnostic ne fonctionnent pas tous en toute transparence avec les applications AOA natives publiées dans .NET 8. Toutefois, tous les outils de diagnostic .NET sont disponibles pour les développeurs pendant la phase de génération d’application. Nous vous recommandons de développer, de déboguer et de tester les applications comme d’habitude et de terminer par la publication de l’application de travail en mode AOT natif.
Débogage natif
Lorsque vous exécutez votre application pendant le développement, comme dans Visual Studio ou avec , ou avec dotnet run, dotnet buildou dotnet test, elle s’exécute sur le runtime .NET complet par défaut. Toutefois, s’il PublishAot est présent dans le fichier projet, le comportement doit être le même entre le runtime .NET complet et l’AOT natif. Cette caractéristique vous permet d’utiliser le moteur de débogage managé Visual Studio standard pour le développement et les tests.
Après la publication, les applications AOT natives sont des fichiers binaires natifs. Le débogueur géré ne fonctionnera pas sur ces éléments. Toutefois, le compilateur AOA natif génère des fichiers exécutables entièrement natifs que les débogueurs natifs peuvent déboguer sur la plateforme de votre choix (par exemple, WinDbg ou Visual Studio sur Windows et GDB ou LLDB sur des systèmes de type Unix).
Le compilateur AOT natif génère des informations sur les numéros de ligne, les types, les variables locales et les paramètres. Le débogueur natif vous permet d'inspecter la trace de la pile et les variables, d'avancer pas à pas dans les lignes de code source ou de les ignorer, ou encore de définir des points d'arrêt.
Pour déboguer des exceptions managées, définissez un point d’arrêt sur la méthode RhThrowEx, qui est appelée chaque fois qu’une exception managée est levée. L’exception est stockée dans le premier registre d’arguments, qui se trouve rcx sur x64 et x0 sur Arm64. Si votre débogueur prend en charge l’affichage des objets C++, vous pouvez caster le registre pour S_P_CoreLib_System_Exception* afin d’afficher plus d’informations sur l’exception.
La collecte d’un fichier de vidage pour une application AOT native implique des étapes manuelles dans .NET 8.
Notes spécifiques à Visual Studio
Vous pouvez lancer un exécutable compilé en mode AOT natif sous le débogueur Visual Studio en l'ouvrant dans l'IDE Visual Studio. Vous devez ouvrir l’exécutable lui-même dans Visual Studio.
Pour définir un point d’arrêt qui s’arrête chaque fois qu’une exception est levée, choisissez l’option Points d’arrêt dans le menu Debug > Windows. Dans la nouvelle fenêtre, sélectionnez Nouveau > Point d’arrêt de fonction. Spécifiez RhThrowEx comme nom de la fonction et laissez l’option Langage sur Tous les langages (ne sélectionnez pas C#).
Pour voir quelle exception a été levée, démarrez le débogage (Déboguer > Démarrer le Débogage ou F5) et lorsque le RhThrowEx point d’arrêt est atteint, ouvrez la fenêtre Watch (Déboguer > Windows > Watch) et ajoutez l’expression suivante comme l’une des surveillances :
| Architecture | L'Expression |
|---|---|
| Architecture x64 | (S_P_CoreLib_System_Exception*)@rcx |
| Architecture Arm64 | (S_P_CoreLib_System_Exception*)@x0 |
Ce mécanisme tire parti du fait que lorsque RhThrowEx est appelé, le registre du processeur mentionné dans la table contient l’exception lancée. Vous pouvez également coller l’expression dans la fenêtre Exécution de Visual Studio ; la syntaxe est la même que pour les montres.
Importance du fichier de symboles
Lors de la publication, le compilateur AOT natif produit un fichier exécutable et un fichier de symboles. Le débogage natif et les activités associées comme le profilage nécessitent l’accès au fichier de symboles natif. Si ce fichier n’est pas présent, il est possible que vous ayez détérioré ou endommagé les résultats.
Pour plus d’informations sur le nom et l’emplacement du fichier de symboles, consultez les Informations de débogage natives.
Profilage du processeur
Des outils spécifiques à la plateforme tels que PerfView et Perf peuvent être utilisés pour collecter des exemples de processeur d’une application AOT native.
Analyse de tas
L'analyse de la mémoire dynamique gérée n'est actuellement pas prise en charge dans Native AOT. Les outils d’analyse de tas tels que dotnet-gcdump, PerfView et les outils d’analyse de tas Visual Studio ne fonctionnent pas en mode AOT natif dans .NET 8.
Voir aussi
Collaborez avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner des issues et des pull requests. Pour plus d’informations, consultez notre guide des contributeurs.
