Déboguer votre extension avec Visual Studio Code

  • 18 minutes

Le processus de recherche et de correction des erreurs s’appelle le débogage. Avec Visual Studio Code et l’extension AL Language, vous obtenez un débogueur intégré pour vous aider à inspecter votre code afin de vérifier que votre application peut s’exécuter comme prévu. Pour démarrer une session de débogage, appuyez sur la touche F5.

Gardez à l’esprit les limitations suivantes :

  • Le code externe ne peut être débogué que si le code a l’indicateur afficherMonCode qui est défini. Vous pouvez définir l’indicateur afficherMonCode dans le fichier de configuration app.json.

  • Le débogueur lance une nouvelle instance du client chaque fois que vous appuyez sur la touche F5. Si vous fermez la session de débogage, puis démarrez une nouvelle session, celle-ci s’appuiera sur une nouvelle instance du client. Nous vous recommandons de fermer les instances du client web lorsque vous fermez une session de débogage.

  • La suspension de la session de débogage n’est pas prise en charge.

Points d’arrêt

Le concept de base du débogage est le point d’arrêt, à savoir une marque que vous définissez sur une instruction. Lorsque le flux de programme atteint le point d’arrêt, le débogueur s’arrête jusqu’à ce que vous lui indiquiez de continuer. En l’absence de points d’arrêt, le code s’exécute sans interruption lorsque le débogueur est actif. Vous pouvez définir un point d’arrêt en utilisant le menu Déboguer dans Visual Studio Code, ou vous pouvez appuyer sur F9 sur la ligne que vous souhaitez déboguer.

Vous pouvez entrer dans le code d’application de base en utilisant la fonctionnalité Atteindre la définition et définir des points d’arrêt sur le code référencé, qui est généralement un fichier (.dal). Pour définir un point d’arrêt sur le code externe ou le code d’application de base, procédez comme suit :

  1. Créez une variable d’un objet de base ou sélectionnez la SourceTable sur une page.

  2. Cliquez avec le bouton droit sur la variable et sélectionnez Atteindre la définition, ou appuyez sur F12. Un fichier externe (fichier .dal) s’ouvre.

  3. Sélectionnez la ligne sur laquelle vous souhaitez placer un point d’arrêt, puis appuyez sur F9.

Raccourcis de débogage

Pendant le débogage, vous pouvez utiliser quelques raccourcis pour démarrer ou arrêter le débogage ou pour effectuer un pas à pas principal ou détaillé du code.

  • F5 : démarrer le débogage

  • Ctrl+F5 : démarrer sans débogage

  • Shift + F5 : arrêter le débogage

  • Ctrl + Shift + F5 : démarrer le débogage sans publication Le débogueur débogue la dernière version publiée, pas la version active dans votre environnement Visual Studio Code.

  • Alt + F5 : démarrer le développement rapide d’application avec le débogage

  • F10 : pas à pas principal

  • F11 : pas à pas détaillé

  • Shift + F11 : pas à pas sortant

  • F12 : atteindre la définition

Arrêt en cas d’erreurs

Dans le fichier de configuration launch.json, vous pouvez spécifier si le débogueur doit s’arrêter sur l’erreur suivante en utilisant la propriété breakOnError. Si le débogueur est défini sur breakOnError, il s’arrête sur les erreurs qui sont gérées dans le code et sur les erreurs non gérées.

La valeur par défaut de la propriété breakOnError est true, ce qui signifie que le débogueur arrête une implémentation qui génère une erreur par défaut. Pour ignorer le processus de gestion des erreurs, définissez la propriété breakOnError sur false dans le fichier launch.json.

Le paramètre breakOnError dans le fichier launch.json prend l’une des valeurs suivantes :

  • true : s’arrête sur toutes les erreurs.

  • false : ne s’arrête sur aucune erreur.

  • Aucune : ne s’arrête sur aucune erreur.

  • Toutes : s’arrête sur toutes les erreurs.

  • ExcludeTry : s’arrête sur les erreurs seulement si elles se produisent en dehors du contexte d’une fonction Try.

Les valeurs true et false sont actuellement conservées à des fins de compatibilité descendante. Elles sont mappées à Toutes et Aucune. Nous vous recommandons d’utiliser ces dernières à l’avenir. Les valeurs true et false pourraient devenir obsolètes dans une future version.

Arrêt en cas de modification de l’enregistrement

Dans le fichier de configuration launch.json, vous pouvez indiquer si le débogueur doit s’arrêter en cas de modification de l’enregistrement à l’aide de la propriété breakOnRecordWrite. Dans le cas où le débogueur est configuré pour s’arrêter en cas de modification de l’enregistrement, il s’arrête avant de créer, de modifier ou de supprimer un enregistrement.

La valeur par défaut de la propriété breakOnRecordWrite est false, ce qui signifie que le débogueur n’est pas configuré par défaut pour s’arrêter en cas de modification de l’enregistrement. Afin qu’il s’arrête en cas de modification de l’enregistrement, définissez la propriété breakOnRecordWrite sur true dans le fichier launch.json.

Le paramètre breakOnRecordWrite dans le fichier launch.json prend l’une des valeurs suivantes :

  • true : s’arrête sur toutes les écritures d’enregistrement.

  • false : ne s’arrête sur aucune écriture d’enregistrement.

  • Aucune : ne s’arrête sur aucune écriture d’enregistrement.

  • Toutes : s’arrête sur toutes les écritures d’enregistrement.

  • ExcludeTemporary : s’arrête sur les écritures d’enregistrement seulement si elles ne se trouvent pas dans une table temporaire.

Les valeurs true et false sont actuellement conservées à des fins de compatibilité descendante. Elles sont mappées à Toutes et Aucune. Nous vous recommandons d’utiliser ces dernières à l’avenir. Les valeurs true et false pourraient devenir obsolètes dans une future version.

Paramètres de la stratégie d’exposition des ressources

Lors du développement d’une extension, votre code, par défaut, est protégé contre le téléchargement ou le débogage. Poursuivez la lecture ici sur l’ajout de la protection de la propriété intellectuelle (PI) contre le téléchargement ou le débogage dans une extension afin de voir le code source dans les extensions.

Le package de développement d’extensions fournit un paramètre préconfiguré pour la protection contre l’affichage ou le téléchargement du code des extensions. Cependant, ce paramètre peut également être contrôlé dans le manifeste, à savoir le fichier app.json.

Lorsque vous démarrez un nouveau projet, un fichier app.json est généré automatiquement. Ce dernier comporte les informations sur l’extension utilisée. Dans le fichier app.json, vous pouvez spécifier un paramètre nommé resourceExposurePolicy qui définit l’accèssibilité des ressources et du code source lors des différentes opérations.

Le paramètre resourceExposurePolicy spécifie la liste d’options suivante :

  • allowDebugging

  • allowDownloadingSource

  • includeSourceInSymbolFile

Chacune de ces propriétés définit les zones spécifiques dans lesquelles le code source d’une extension est accèssible. Toutes les options par défaut sont définies sur false. Autrement dit, par défaut, aucune extension dépendante ne peut déboguer ou télécharger le code source de votre extension.

Voici un exemple de fichier JSON avec des valeurs par défaut lorsqu’il est généré à l’aide de AL: Go! Commande :

... "resourceExposurePolicy": { "allowDebugging": true, "allowDownloadingSource": false, "includeSourceInSymbolFile": false }, "runtime": "8.0", "keyVaultUrls": [ "https://mykeyvault.vault.azure.net" ], "applicationInsightsConnectionString": "MyConnectionString1234" ...

Le paramètre resourceExposurePolicy n’est pas visible dans le fichier app.json lorsqu’il est généré. Si vous souhaitez modifier la valeur par défaut false, vous devez ajouter le paramètre comme indiqué dans l’exemple de syntaxe ci-dessus.

allowDebugging

Pour autoriser le débogage dans votre extension, lorsque l’extension est considérée comme une dépendance, vous devez définir l’indicateur allowDebugging, sinon le débogage n’est pas autorisé. Si vous souhaitez autoriser les débogueurs de votre extension à afficher le code source, la propriété allowDebugging du fichier app.json doit être définie sur true.

Par exemple, si un développeur développe l’extension A et que lui ou un autre membre de l’équipe développe l’extension B, et que B dépend de A, alors le débogage de B n’interviendra dans le code de A que si une méthode de A est appelée et que l’indicateur allowDebugging est défini sur true dans le fichier app.json de l’extension A.

À moins que vous n’ayez spécifié l’attribut [NonDebuggable] sur les méthodes et les variables, la définition de la propriété allowDebugging sur true permettra d’entrer dans ce code. Toutefois, si vous avez marqué les méthodes et les variables à l’aide de l’attribut [NonDebuggable], celles-ci ne pourront toujours pas être déboguées.

La valeur par défaut de l’indicateur allowDebugging est false. Il est recommandé de ne définir cet indicateur sur true que si vous faites confiance à la personne qui étend votre extension. Si allowDebugging est défini sur true, toute personne qui étend votre code a accès à son débogage. Si vous souhaitez autoriser uniquement certaines personnes à accéder à votre code, vous pouvez remplacer la stratégie de ressources.

Dans quelques cas, le code peut être débogué alors que l’indicateur allowDebugging est défini sur false. Les voici :

  • Une personne peut continuer à voir votre code si une extension est déployée au moyen de Visual Studio Code en tant qu’extension DEV plutôt qu’à l’aide d’un cmdlet, à l’aide de la page Gestion des extensions de Business Central ou d’AppSource.

  • Les outils externes personnalisés pour AL peuvent accéder aux informations DAL exposées par le débogueur en écoutant les événements du débogueur déclenchés par Visual Studio Code.

allowDownloadingSource

Lorsque ce paramètre est défini sur true dans le fichier app.json de l’extension A, le code source et tous les fichiers multimédias de l’extension A peuvent être téléchargés. Par exemple, à partir de l’option Télécharger la source de la page Gestion des extensions dans Business Central. L’extension A peut être une extension PTE ou DEV. La valeur par défaut de l’indicateur allowDownloadingSource est false.

includeSourceInSymbolFile

Lorsque ce paramètre est défini sur true dans le fichier app.json de l’extension A, le fichier de symboles téléchargés dans Visual Studio Code, accèssible à l’aide de la fonctionnalité Téléchargement de symboles, comporte des symboles, le code source et toutes les autres ressources de l’extension A. Atteindre la définition pour voir le code dépend également de cette propriété. La valeur par défaut de l’indicateur includesourceInSymbolFile est false.

Messages de diagnostic du compilateur AL

Lorsque vous compilez ou exécutez des analyseurs de code, des messages de diagnostic peuvent apparaître sous la forme de messages d’erreur, d’avertissement ou d’information. Pour aider à résoudre ces problèmes de diagnostic, ces messages comportent désormais une URL vers une documentation supplémentaire sur la cause du problème et les options de résolution possibles.

Les messages de diagnostic de compilation ou d’analyseurs de code prennent en charge des liens vers une documentation supplémentaire pertinente sur la cause du problème et les options de résolution possibles.

Il existe des pages de documentation pour tous les problèmes de diagnostic et les liens URL des diagnostics de sortie de compilateur. Toutefois, la documentation est initialement superficielle et comporte principalement le message. Nous demandons aux partenaires de nous aider en fournissant des commentaires afin d’identifier les rubriques nécessitant en priorité une documentation supplémentaire, et de partager des commentaires sur le contenu utile pour contribuer à résoudre les problèmes. La documentation s’enrichit ainsi au fil du temps et les connaissances entre les partenaires sont partagées grâce à ces conseils et astuces sur les causes et les correctifs, ce qui contribue à réduire le temps consacré à chaque diagnostic.

Pour obtenir des exemples et des références, consultez l’article Diagnostics du compilateur AL actuel.

Lancement dans une société spécifique à partir de Visual Studio Code

Vous pouvez disposer de plusieurs sociétés dans un abonné Business Central. Lorsque vous déboguez ou testez votre application, vous souhaitez souvent le faire dans le contexte d’une société spécifique. Dans les versions antérieures de Business Central, vous ne pouviez pas contrôler la société à utiliser lorsque vous lanciez le client à partir de Visual Studio Code. En général, vous devez d’abord configurer la société par défaut dans le client.

Un nouveau paramètre startupCompany a été ajouté au fichier de configuration Visual Studio Code launch.json. Il vous permet de spécifier la société à utiliser lorsque le client est lancé à partir de Visual Studio Code, par exemple lorsque vous effectuez une exécution ou un débogage.

Afficher les informations SQL Server pendant le débogage AL

Comprendre les verrouillages de base de données lors du développement et de la résolution des problèmes dans des bacs à sable cloud sans accès SQL direct peut être compliqué. Il peut être difficile d’identifier les verrouillages pris à partir d’AL lors de l’appel, par exemple, de la méthode rec.Modify() ou rec.FindSet(). Bien que les verrouillages SQL soient désormais visibles dans le client web, leur utilisation à des fins de débogage est fastidieuse, car vous avez besoin d’un autre navigateur avec une autre session.

Pour vous faciliter la tâche, la section Statistiques de base de données de la fenêtre Variables pour l’expérience de débogage AL Visual Studio Code a été étendue pour afficher les verrouillages SQL pour la session déboguée.

Outre les dernières instructions SQL exécutées et les statistiques de base de données, vous pouvez également obtenir des informations sur les verrouillages SQL actifs survenant lors de la session en cours de débogage. La liste est mise à jour lorsque vous parcourez le code AL. Les validations suppriment les verrouillages conservés.

Déboguer l’application système

Avec l’introduction récente du type de données SecureText, nous avons permis le débogage de l’application système, bénéficiant à la fois au développement et au dépannage des applications, ainsi qu’aux contributions open source à l’application système elle-même.

Avec cela, vous pourrez accéder à la base de code de l’application système lors du débogage pour comprendre le flux de code et inspecter les variables, à moins que celles-ci ne soient protégées par le nouveau type SecureText.

L’accès au débogage de l’application système est utile à la fois pendant le développement et le dépannage des applications AppSource et spécifiques au client, ainsi que pour contribuer à l’application système elle-même à l’aide de https://github.com/microsoft/BCApps.