Configurer des projets et des espaces de travail
Visual Studio Code offre la fonctionnalité d’espace de travail multi-racine, qui permet de regrouper différents dossiers de projet dans un seul espace de travail. L’extension AL Language prend également en charge la fonctionnalité multi-racine et permet d’utiliser plusieurs dossiers AL dont les racines et les projets dans un seul espace de travail.
Pour utiliser simultanément plusieurs projets associés, procédez comme suit :
Dans l’onglet Fichier de Visual Studio Code, choisissez Ajouter un dossier à l’espace de travail…
Enregistrez le fichier de l’espace de travail si vous prévoyez de le rouvrir.
Ces étapes entraînent la création d’un fichier code-workspace qui comporte un tableau de dossiers avec des chemins d’accès absolus ou relatifs. Pour partager vos fichiers d’espace de travail, choisissez les chemins d’accès relatifs.
Modifiez les paramètres de vos fichiers dans l’éditeur Paramètres. Vous pouvez modifier les paramètres utilisateur, les paramètres généraux de l’espace de travail ou des paramètres de dossier individuels.
Il n’est pas obligatoire d’utiliser uniquement des racines basées sur AL. Différents types de projets peuvent être mélangés et chaque projet AL dispose de ses valeurs de configuration pour les paramètres suivants :
al.packageCachePath
al.enableCodeAnalysis
Le paramètre al.packageCachePath vous permet de spécifier le chemin d’accès à un dossier faisant office de cache pour les fichiers de symboles utilisés par votre projet. Il peut être spécifié dans les Paramètres utilisateur, les Paramètresde l’espace de travail ou les Paramètres du projet.
Le paramètre al.enableCodeAnalysis vous permet d’activer l’exécution d’analyseurs de code sur votre projet. De même, il peut être spécifié dans les Paramètres utilisateur, les Paramètresde l’espace de travail ou les Paramètres du projet.
Une référence de projet dans un espace de travail basé sur AL est définie comme une dépendance dans le fichier app.json et existe en tant que projet dans l’espace de travail. Il n’y a pas de représentation visuelle spéciale d’une référence de projet.
Une référence de projet est l’ID complet, le nom, l’éditeur et la version d’un projet existant dans l’espace de travail. Elle est l’opposé d’une référence d’application, où il suffit de spécifier une version minimale. Si vous utilisez des espaces de travail avec plusieurs projets et modifiez le nom ou l’éditeur d’une extension dans l’espace de travail, les dépendances dans le fichier app.json doivent être mises à jour avec le nouveau nom et le nouvel éditeur ou vous pouvez rencontrer des problèmes avec la résolution de référence.
Dans l’exemple suivant, le projet nommé Leaf définit deux dépendances aux projets Middle et Root. Comme Root et Middle sont des projets dans l’espace de travail, ils sont considérés comme des références de projet.
L’avantage d’utiliser des références de projet est qu’il n’est pas nécessaire de télécharger les symboles d’une référence de projet. Ils sont là en tant que symboles pour le projet de référence et sont résolus au fur et à mesure de leur modification. Par exemple, si vous ajoutez une nouvelle méthode à un codeunit dans le projet Root et référencez le codeunit dans le projet Leaf, la méthode est résolue automatiquement lorsque vous modifiez le projet Leaf.
Lorsqu’un projet est créé avec le raccourci clavier Ctrl + Shift + B, voici ce qui se passe :
Le fichier .app est copié dans le dossier .alpackages de tous les projets qui en dépendent.
Toutes les références de projet pouvant être « sales » sont également créées.
Si la résolution de référence cesse de fonctionner, la création de la référence de projet et la réinitialisation de l’espace de travail à l’aide de la commande Reload Window résolvent les références.
Lorsqu’un projet se charge dans un espace de travail, il tente de charger toutes ses références de projet en tant qu’opération transitive. Pendant le chargement d’un projet, des fonctionnalités telles qu’IntelliSense et le survol ne sont pas disponibles. Selon le nombre de références de projet et de fichiers dans le projet, cette opération peut être chronophage.
Lorsque le projet se charge dans l’espace de travail, l’utilisateur est averti de l’état actuel par les boîtes de dialogue standard Visual Studio Code de notification de progression. Les notifications peuvent être fermées, mais elles n’arrêtent pas le chargement d’un projet. Si l’utilisateur clique ailleurs ou modifie le projet actif, le chargement du projet précédent est annulé et le projet actif nouvellement sélectionné commence à se charger à la place. Un projet peut être chargé en le rendant actif, en ouvrant un fichier .al ou en ouvrant le fichier de projet app.json. Une fois qu’un projet est chargé, il reste chargé jusqu’à ce que le serveur de langage AL soit actif ou que la commande Reload Window soit déclenchée à l’aide du raccourci clavier Ctrl + R.
Les projets non chargés dans l’espace de travail sont décorés de la lettre N.
Avec l’introduction des références de projet, la logique de publication dans un espace de travail a changé. La publication avec le raccourci clavier Ctrl + F5 ou la publication RAD à l’aide du raccourci clavier Alt + Ctrl +F5 effectue une publication définie de tous les projets modifiés avec la définition d’un projet de démarrage. Le projet de démarrage est toujours le projet actif.
Un projet est considéré comme modifié si l’un de ses objets d’application a changé dans le sens où l’objet d’application se trouve déjà dans le fichier rad.json ou y sera une fois le projet créé. Autrement dit, si vous modifiez un objet d’application, que vous l’enregistrez, puis fermez Visual Studio Code sans créer le projet, le fichier rad.json n’est pas mis à jour, puis le projet n’est pas considéré comme « sale ».
Par exemple, dans un espace de travail avec trois projets, à savoir Leaf, Middle et Base, Leaf dépend de Middle et Base, et Middle dépend de Base, comme illustré dans le schéma suivant :
Prenons les hypothèses suivantes :
Les trois projets Leaf, Base et Middle ont été modifiés.
Le projet Leaf est le projet en cours publié.
Dans ce cas, les trois projets Base, Middle et Leaf font partie de l’ensemble publié.
Dans un scénario où Middle n’a pas été modifié, mais où Leaf est toujours le projet de démarrage, seuls Base et Leaf sont publiés.
Un fichier est créé pour mettre en package les dépendances d’ensemble nommées *.dep.app. Ce fichier est transféré sur le serveur et supprimé si la publication de l’ensemble de dépendances réussit.
Bien que la publication de serveur soit une étape interne, elle a un impact sur la publication des dépendances et il est utile de la connaître.
Par exemple, dans un espace de travail avec deux projets, Leaf dépend de Base, et External et Indirect sont des projets en dehors de l’espace de travail, comme illustré ci-dessous :
Prenons les hypothèses suivantes :
Un espace de travail existe avec Leaf et Base en tant que projets d’espace de travail.
Base est publié.
Sur le serveur, Base, Leaf, External et Indirect sont des applications déjà installées.
Les événements suivants se produisent sur le serveur :
Toutes les applications qui dépendent de Base sont désinstallées, y compris la dépendance à External et Indirect.
Toutes les autres applications dépendant directement de Base et non publiées dans l’étendue globale (dans ce cas Leaf et External) ne sont pas publiées.
Base est désinstallée, sa publication est annulée, puis l’application est publiée.
Leaf et External sont publiées, installées, puis compilées par rapport à l’application Base nouvellement publiée. Notez ici que l’application External est également publiée.
Pour contrôler la publication des dépendances sur le serveur, le fichier launch.json comporte un paramètre dependencyPublishingOption avec les options suivantes :
Par défaut
- La publication des dépendances d’ensemble est appliquée.
Ignorer
- La publication des dépendances est ignorée. Ce paramètre doit être utilisé avec précaution. Voir la note ci-dessous.
Strict
- La publication des dépendances échoue si des applications installées dépendent du projet de démarrage.
Avec le paramètre Ignorer, seule Leaf est publiée par rapport à ce qui a déjà été publié sur le serveur pour Middle et Base. Si une modification effectuée sur Base rompt Leaf, la compilation du serveur échoue dans ce scénario, même si la compilation locale réussit. L’avantage d’utiliser cette option est de réduire le temps de publication lorsque Base est un grand projet. En supposant que Base est publiée, Leaf et Middle ne sont pas modifiées sur le serveur. Seules les erreurs d’exécution révèlent si Base a rompu Middle et Leaf.
Supprimez le travail manuel inutile à l’aide de la commande AL: Publish full dependency tree for active project, qui parcourt un graphe de dépendances de projet dans l’espace de travail et installe tous les projets requis s’ils ne sont pas encore déployés sur le serveur NST. Recherchez la commande à l’aide du raccourci clavier Ctrl + Shift + P ou Shift + Alt + W. Cela entraîne le calcul de l’ordre adéquat dans lequel compiler et publier les dépendances du projet en cours et les publier à l’aide de l’option launch.json sélectionnée dans le projet actif en cours.
Seules les références de projet et d’application couvertes par l’espace de travail sont parcourues. Si le projet AL déployé a des dépendances à des applications non incluses dans l’espace de travail, celles-ci doivent toujours être présentes ou déployées manuellement à l’avance.
Si le paramètre al.incrementalBuild est défini sur true dans les espaces de travail avec des références de projet à projet, toutes les résolutions se produisent à partir du projet référencé, au lieu de se produire à partir d’une application dans le dossier \packagecache, ce qui réduit le temps de création.