Gestion des dépendances

Les dépendances du projet dans Studio font référence à des paquets liés à un projet spécifique, contenant des activités, par défaut ou personnalisées. Les dépendances sont contextuelles et prennent en compte la définition de chaque projet, y compris les activités qu'il utilise, les variables, les arguments d'entrée/de sortie. Par conséquent, une dépendance est définie uniquement si elle comprend au moins une référence dans la définition du projet.

Tous les modèles de projet disponibles dans Studio sont fournis avec leurs propres packages de dépendances par défaut.

Dans StudioX, tous les projets sont livrés avec les packages par défaut suivants : UiPath.System.Activities, UiPath.ComplexScenarios.Activities, UiPath.Excel.Activities, UiPath.Mail.Activities, UiPath.Presentations.Activities,UiPath.UIAutomation.Activitieset UiPath.Word.Activities.

Si d'autres doivent être ajoutés, cliquez sur le bouton Gérer les paquets (Manage Packages) dans le ruban et installez-les. Les dépendances installées sont disponibles uniquement pour le projet actuel, et la liste de dépendances par projet est visible dans le fichier project.json.

Le panneau Projet (Project) affiche les paquets d'activités installés dans le projet d'automatisation, avec leurs sous-dépendances, règles de runtime, versions demandées et résolues.

Pointez sur une dépendance pour voir les versions demandées et résolues. Les actions contextuelles, telles que Gérer (Manage), Réparer (Repair) ou Supprimer la dépendance (Remove Dependency) sont disponibles uniquement pour les dépendances et non pour leurs sous-paquets. Les dépendances non résolues sont marquées en gris dans l'arborescence, les dépendances introuvables en rouge, tandis que les dépendances résolues et de correspondance exacte en bleu décoloré et vif.

Ajout et mise à jour de dépendances

Chaque fois que de nouvelles versions sont disponibles pour les dépendances du projet actuel, le bouton Gérer les paquets (Manage Packages) du ruban obtient une icône de mise à jour .

1. Pour gérer des dépendances dans un projet, cliquez simplement avec le bouton droit dans la catégorie Dépendances (Dependencies) du panneau Projet (Project), puis cliquez sur Gérer (Manage). Cela ouvre la fenêtre Gérer les paquets (Manage Packages), avec la catégorie Dépendances du projet (Project Dependencies). L'icône affiche quels paquets sont actuellement installés.

   
   

   

   
   
2. Les dépendances par défaut s'affichent, avec les versions actuellement liées au projet. Pour mettre à jour un paquet, il suffit de cliquer sur l'icône de mise à jour , en regard du numéro de version disponible. L'icône s'affiche en regard du paquet. Cela indique que les dépendances sont prêtes à être installées.
3. Les dépendances ne sont installées dans le projet qu'une fois que vous avez cliqué sur Enregistrer. Simultanément, les versions des dépendances sont mises à jour dans le fichier project.json appartenant au projet.

Pour ajouter des dépendances à un projet, il suffit de les rechercher et de les installer comme vous le feriez avec tout paquet d'activités. Pour plus d'informations, consultez la page Gérer des paquets (Manage Packages).

Suppression de dépendances

1. Pour supprimer une dépendance du projet, cliquez simplement avec le bouton droit sur la dépendance dans le panneau Projet (Project).
2. Sélectionnez Supprimer la dépendance (Remove Dependency). La dépendance est supprimée du panneau Projet (Project) et du fichier project.json.

Cela peut se faire également en cliquant simplement sur le bouton Désinstaller (Uninstall) disponible pour chaque dépendance de la catégorie Gérer des paquets (Manage Packages) > Dépendances du projet (Project Dependencies).

Réparation de dépendances

Si un workflow ouvert dans Studio possède des références vers les paquets ayant des versions non disponibles dans les flux Studio actuels, les dites dépendances sont marquées comme endommagées dans le panneau Projet (Project). Des détails sont disponibles dans le panneau Sortie (Output).

Studio permet de réparer toutes les dépendances en bloc ou individuellement. Pour réparer toutes les dépendances endommagées, cliquez avec le bouton droit sur le nœud Dépendance (Dependency) dans le panneau Projet (Project), et cliquez sur Réparer les dépendances (Repair Dependencies).

Cliquez avec le bouton droit sur une dépendance endommagée et sélectionnez Résoudre la dépendance (Resolve Dependency) pour la réparer individuellement. Vous pouvez également sélectionner Gérer (Manage) pour ouvrir la fenêtre Gérer des paquets (Manage Packages) et mettre à jour les paquets.

NuGet résout les dépendances endommagées en appliquant la règle de runtime Version applicable la plus ancienne (Lowest Applicable Version) . Cela implique qu'il recherche la première version applicable, supérieure à celle définie précédemment.

Remarque : les activités manquantes ou non valides sont marquées dans le panneau Concepteur (Designer), tandis qu'une bannière d'erreur fournit des informations concernant le workflow et ses conflits de dépendances non résolus.

Définition des règles de dépendances

Les paquets d'activités sont disponibles dans plusieurs versions. C'est la raison pour laquelle leur installation ou mise à jour à l'aide de la fenêtre Gérer des paquets (Manage Packages) permet de définir des règles de runtime de dépendances pour chacun d'entre eux.

La Règle de runtime (Runtime Rule) spécifie quelle version de paquet installer au runtime. Elle présente deux options disponibles.

La règle de runtime Strict (Strict) est l'état par défaut des dépendances ajoutées lors de la création du processus, et pour les paquets d'activités installés depuis la fenêtre Gérer les paquets (Manage Packages). Cela implique que seule la version spécifiée du paquet est utilisée au runtime pour exécuter le processus parent. La règle Strict (Strict) est marquée dans le panneau Projet (Project), sous Dépendances (Dependencies) par le signe en regard de la version du paquet.

La règle de runtime Version applicable la plus ancienne (Lowest Applicable Version) implique que si le paquet cible est introuvable, la version supérieure suivante est recherchée afin de résoudre les dépendances. La règle Version applicable la plus ancienne (Lowest Applicable Version) est marquée dans le panneau Projet (Project), sous Dépendances (Dependencies) par le signe en regard de la version du paquet.

Lorsqu'un projet d'automatisation est exécuté à partir de Studio, le Robot télécharge la version de paquet spécifiée requise pour exécuter le projet, conformément aux règles de runtime définies précédemment pour chaque projet. Si la dépendance utilisée lors de l'exécution possède une règle de runtime Strict (Strict) et que la version de paquet exacte est introuvable, une erreur est générée. Pour plus d'informations sur la définition des règles de runtime pour les dépendances du projet, consultez la page Gestion des dépendances.

Résolution des conflits de dépendances

L'installation des paquets d'activités prennent en compte les règles de runtime des dépendances auparavant définies pour les dits paquets. Toutefois, certains conflits entre les versions peuvent se produire lors de l'automatisation des projets. Le projet d'automatisation et la bibliothèque qu'il contient peuvent posséder le même paquet d'activités, mais avec des versions et des règles de runtime différentes. Au moment de la conception, NuGet résout de tels conflits en choisissant la dépendance de niveau supérieur, qui est la plus proche du projet de la hiérarchie.

La résolution des conflits qui peut se produire est expliquée ci-dessous :

Le projet contient un paquet d'activités avec la version 1.0. La bibliothèque est référencée vers le projet et utilise le même pack, mais avec une version supérieure. La dépendance de niveau supérieur v1.0 est utilisée au runtime. Un avertissement s'affiche, mentionnant ainsi qu'une rétrogradation a été détectée.

La résolution de ce scénario est applicable, indépendamment de la règle de runtime (Strict (Strict) ou Version applicable la plus ancienne (Lowest Applicable Version) ) auparavant définie pour les paquets d'activités.

• Si vous choisissez Oui, le package d’activités référencé dans le projet est mis à niveau vers la version utilisée dans la bibliothèque.

• Si vous choisissez Non (No), la fenêtre Gérer des paquets (Manage Package) s'ouvre avec la fenêtre Dépendances du projet (Project Dependencies).

  
  

  

  
  

Le projet contient un paquet d'activités avec la version 2.0. La bibliothèque utilise le même pack, mais avec une version antérieure et la règle de runtime Strict (Strict) . La dépendance de niveau supérieur utilisé dans ce cas est la version v2.0 et un avertissement s'affiche lorsque le paquet est installé dans le projet.

Le projet contient un paquet d'activités avec la version 2.0. La bibliothèque utilise le même pack, mais avec une version antérieure et la règle de runtime Version applicable la plus ancienne (Lowest Applicable Version) . La dépendance de niveau supérieur utilisé dans ce cas est la version v2.0 et un avertissement s'affiche lorsque le paquet est installé dans le projet.

Le projet référence une bibliothèque avec une version 1.0 du paquet d'activités et une règle de runtime Strict (Strict) . Le projet référence une autre bibliothèque, mais avec une version 2.0 du paquet d'activités. La dépendance de niveau supérieur utilisé dans ce cas est v2.0 et elle possède la version supérieure. Un avertissement s'affiche lorsque le paquet d'activités est installé.

Dans ce conflit, le projet référence deux bibliothèques, dont les dépendances Strict (Strict) sont référencées tour à tour entre elles. Ce scénario n'est pas pris en charge. Pour obtenir des informations détaillées, consultez la page Résolution des dépendances (Dependency Resolution).

Les cycles de dépendance sont des types de conflits qui se produisent lorsqu'un package se référence lui-même. Si vous nommez votre projet UiPath, Studio détecte un conflit de dépendance. Cela se produit car le package UiPath existe déjà et est une dépendance de UiPath.UIAutomation.Activities. Il est recommandé d'éviter de nommer votre projet avec le nom d'un package déjà existant que vous avez l'intention d'ajouter en tant que dépendance.

Le même cycle de dépendance se produit si vous ouvrez un fichier .xaml à partir d'un dossier nommé UiPath ou de tout nom d'un package existant que vous avez l'intention d'ajouter en tant que dépendance, et qu'il n'y a pas de project.json dans ce dossier. Lorsque vous ouvrez un fichier .xaml auquel aucun fichier project.json n'est associé, Studio en crée un et la balise "name" est renseignée avec le nom du dossier parent.

Ouverture de projets créés avec des versions précédentes

Attention : l’ouverture de projets créés avec Studio v2016.2 directement dans v2020.4 n'est pas pris en charge. Tout d’abord, ouvrez ces projets avec Studio v2018.4, puis avec v2020.4 ou plus récent.

Lorsque vous ouvrez un projet avec ou sans dépendances conçues avec une version antérieure à v2018.3 (sauf pour la version v2016.2), Studio vous demande si une migration automatique doit être effectuée, afin qu'elle puisse tenter de récupérer des dépendances manquantes ou d'en ajouter par défaut.

Sur confirmation, Studio tente de récupérer les dépendances manquantes et définit la règle de runtime Strict (Strict) pour les paquets qu'il trouve. Lorsque vous utilisez l'option Réparer la dépendance (Repair Dependency) dans le panneau Projet (Project), Studio tente d'installer la meilleure version de paquet suivante. Si la version de paquet est introuvable, des alertes s'affichent dans le panneau Sortie (Output). Vous devez vérifier les flux configurés dans la fenêtre Gérer des paquets (Manage Package).

Les processus contenant des dépendances et qui ont été créées avec des versions de Studio antérieures à v2018.3 continuent d'être exécutées à l'aide de Robot v2018.3. La règle de runtime pour de tels projets est définie sur Version applicable la plus ancienne (Lowest Applicable Version) .

Les projets créés avec des versions antérieures à la version v2018.3, qui n'ont jamais été publiés, n'ont pas de dépendances répertoriées dans le fichier project.json. Lors de l'ouverture de ces projets, une alerte dans le panneau Sortie (Output) vous informe des dépendances manquantes. Les paquets UiPath transmis localement avec Studio sont ajoutés en tant que dépendances avec la règle de runtime Strict (Strict) . La dernière version de tels paquets est définie automatiquement.

Si ces projets contiennent des paquets autres que ceux fournis avec Studio localement, nous recommandons les actions suivantes :

• Publication du projet à l'aide de la version Studio dans laquelle il a été créé, facilitant ainsi le processus de migration en ajoutant des dépendances dans le fichier project.json ;
• Installation manuelle du paquet manquant depuis la fenêtre Gérer des paquets (Manage Packages), après avoir configuré le flux requis ;

• Utilisation de l'outil Mise à jour groupée des dépendances du projet (Project Dependencies Mass Update) pour ajouter la dépendance manquante à une majorité de projets.

  Remarque : les workflows contenant des activités non valides ne peuvent pas être enregistrés. Installez la dépendance nécessaire, puis enregistrez le projet.

Les packages d'activités UiPath.V7.Activities, UiPath.Platform.Activities, UiPath.Framework.Activities ont été désapprouvés. Lors de l'ouverture des projets avec les paquets UiPath.Platform.Activities et UiPath.Framework.Activities, Studio v2018.3 ou versions ultérieures tente d'effectuer une migration automatique pour remplacer les anciennes versions des activités par de nouvelles.

Remarque : les workflows contenant l'élément activités du paquet UiPath.V7.Activities ne peuvent pas être migrés.

Une solution est disponible pour certains cas dans lesquels la migration n'est pas effectuée automatiquement.

1. Ouvrez le fichier project.json avec Notepad++.
2. Supprimez le paramètre "schemaVersion": "3.2".
3. Remplacez "studioVersion" par "toolVersion".
4. Passez la valeur "toolVersion" de "18.3.xxx" à une version précédente. Par exemple, passez la valeur de "18.3.0.958" à "18.2.958". Enregistrez le fichier.
5. Ouvrez le fichier .xaml avec Studio v2018.3 ou versions ultérieures pour que la migration soit effectuée. Les paquets d'activités désapprouvés sont remplacés par de nouveaux, comme illustré dans la section Dépendances (Dependencies) du panneau Projet (Project).
   Remarque : dans certains cas, les fichiers .xaml contenant les packages UiPath.Platform.Activities et UiPath.Framework.Activities ne peuvent pas être migrés automatiquement et la solution de contournement n'est pas applicable. Pour ces situations, il est recommandé d'ouvrir les projets dans Studio v2018.2 ou version antérieure et de remplacer les activités appartenant aux packages susmentionnés par les activités contenues dans le package UiPath.Core.Activities. La même chose peut être faite pour les workflows contenant des activités du package UiPath.V7.Activities.

À partir de Studio v2018.4.1, Microsoft.Activities v.1.0.1 et Microsoft.Activities.Extensions v2.0.6.9 ne sont plus intégrés au programme d'installation UiPathStudio.msi.

Au cas où une réparation serait nécessaire lors de la migration de projets contenant ces packs en tant que dépendances, installez les deux paquets à partir du flux Officiel (Official) ou d'un flux local. Avant d'exécuter de tels projets créés à l'aide de versions antérieures à v2018.4.1, assurez-vous que les paquets susmentionnés sont disponibles dans un flux accessible par le Robot.

Si vous effectuez la mise à niveau à partir d'une version antérieure à v2018.4.1, les deux paquets d'activités demeurent dans le flux Local (Local).