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.

Dans Studio, les dépendances par défaut d'un projet diffèrent selon le type de projet, la compatibilité ou le modèle utilisé pour créer le projet.

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 packages 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. La compatibilité du projet est visible dans le nœud Dépendances (Dependencies).

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-packages.

Le statut des dépendances dans l’arborescence est codé par couleur comme suit :

• Rouge : la dépendance est introuvable.
• Orange : un sous-package est introuvable.
• Gris : la dépendance n’est pas résolue.
• Bleu pâle : la version résolue est supérieure à la version demandée.
• Bleu foncé : il y a une correspondance exacte entre la version demandée et la version résolue.

Ajout et mise à jour de dépendances

Pour ajouter des dépendances à un projet, installez-les à partir de la fenêtre Gérer les packages. Veuillez noter que les packages disponibles diffèrent en fonction de la compatibilité du projet.

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.

Suppression de dépendances

• Pour supprimer une dépendance de projet, cliquez avec le bouton droit sur la dépendance dans le panneau Projet , puis sélectionnez Supprimer la dépendance. La dépendance est supprimée du panneau Projet et du fichier project.json.

  Alternativement, vous pouvez accédez à Gérer les paquets (Manage Packages) > Dépendances du projet (Project Dependencies), sélectionner la dépendance à supprimer, puis cliquer sur Désinstaller (Uninstall).

• Pour supprimer toutes les dépendances inutilisées dans le projet, sélectionnez Supprimer les dépendances inutilisées (Remove Unused) > Dépendances (Dependencies) dans le ruban de Studio, ou utilisez le raccourci clavier Ctrl + Maj + R. Tous les packages installés qui n'ont aucune référence dans le projet actuel sont supprimés du panneau Projet et du fichier project.json.

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.

Si la version cible est introuvable, la fonction de réparation utilise automatiquement la prochaine version supérieure disponible. Veuillez noter que ce comportement dépend de la configuration du flux.

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 ou des versions plus récentes n'est pas prise 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.

Lors de la confirmation, Studio tente de récupérer les dépendances manquantes et définit la règle d’exécution Strict pour les packages qu’elle 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 package suivante. Si la version du package est introuvable, les alertes s’affichent dans le panneau Sortie (Output) et vous devez vérifier les flux configurés dans la fenêtre Gérer les packages (Manage Packages).

Les processus contenant des dépendances et qui ont été créés avec des versions de Studio antérieures à v2018.3 continuent d’être exécutés à 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 packages UiPath® transmis localement avec Studio sont ajoutés en tant que dépendances avec la règle de runtime Strict. La dernière version de ces packages 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).