Verwalten von Abhängigkeiten

Projektabhängigkeiten in Studio beziehen sich auf Pakete, die mit einem bestimmten Projekt verbunden sind, das entweder Standard- oder benutzerdefinierte Aktivitäten enthält. Abhängigkeiten sind kontextbedingt und berücksichtigen die Definition jedes Projekts, einschließlich der verwendeten Aktivitäten, Variablen und Eingabe-/Ausgabeargumente. Daher wird eine Abhängigkeit nur definiert, wenn sie mindestens einen Verweis in der Projektdefinition enthält.

Alle in Studio verfügbaren Projektvorlagen verfügen über eigene Standardabhängigkeitspakete.

In StudioX werden alle Projekte mit den folgenden Standardpaketen geliefert: UiPath.System.Activities, UiPath.ComplexScenarios.Activities, UiPath.Excel.Activities, UiPath.Mail.Activities, UiPath.Presentations.Activities,UiPath.UIAutomation.Activitiesund UiPath.Word.Activities.

Wenn weitere hinzugefügt werden müssen, klicken Sie auf die Schaltfläche Pakete verwalten (Manage Packages) und installieren Sie diese. Installierte Abhängigkeiten stehen nur für das aktuelle Projekt zur Verfügung und die Liste der Abhängigkeiten pro Projekt ist in der Datei project.json zu sehen.

Im Panel Projekt-Panel werden die im Automatisierungsprojekt installierten Aktivitätspakete zusammen mit ihren Unterabhängigkeiten, Laufzeitregeln sowie den angeforderten und aufgelösten Versionen angezeigt. Die Projektkompatibilität wird im Knoten Abhängigkeiten angezeigt.

Zeigen Sie mit der Maus auf eine Abhängigkeit, um die angeforderten und aufgelösten Versionen anzuzeigen. Kontextabhängige Aktionen wie Verwalten, Reparieren oder Abhängigkeit entfernen stehen nur für Abhängigkeiten und nicht für deren Unterpakete zur Verfügung.

Der Status der Abhängigkeiten in der Baumstruktur ist wie folgt farbcodiert:

• Rot – Die Abhängigkeit wurde nicht gefunden.
• Orange – Ein Unterpaket wurde nicht gefunden.
• Grau – Die Abhängigkeit ist nicht aufgelöst.
• Hellblau – Die aufgelöste Version ist höher als die angefragte Version.
• Dunkelblau – Es gibt eine genaue Übereinstimmung zwischen der angeforderten Version und der aufgelösten Version.

Hinzufügen und Aktualisieren von Abhängigkeiten

To add dependencies to a project, install them from the Manage Packages window. Please note that the available packages differ based on the project compatibility.

Whenever new versions are available for the current project dependencies, the Manage Packages button from the ribbon gets an update icon .

1. Um die Abhängigkeiten in einem Projekt zu verwalten, klicken Sie einfach mit der rechten Maustaste auf die Kategorie Abhängigkeiten im Panel Projekt (Project) und anschließend auf Verwalten. Dies öffnet das Fenster Pakete verwalten (Manage Packages) mit der Kategorie Projektabhängigkeiten (Project Dependencies). Das Symbol zeigt an, welche Pakete aktuell installiert sind.

   

2. Default dependencies are displayed, together with the versions that are currently linked to the project. To update a package, simply click on the update icon , next to the available version number. The icon is shown next to the package, meaning that dependencies are ready to be installed.

3. Abhängigkeiten werden nur nach Klicken auf Speichern (Save) im Projekt installiert. Gleichzeitig werden die Versionen von Abhängigkeiten in der Datei project.json aktualisiert, die zu dem Projekt gehört.

Entfernen von Abhängigkeiten

• Um eine Projektabhängigkeit zu entfernen, klicken Sie im Projekt-Panel mit der rechten Maustaste auf die Abhängigkeit und wählen Sie dann Abhängigkeit entfernen aus. Die Abhängigkeit wird aus dem Projekt-Panel und der project.json-Datei entfernt.

  Alternativ können Sie zu Pakete verwalten > Projektabhängigkeiten wechseln , die zu entfernende Abhängigkeit auswählen und dann auf Deinstallieren klicken.

• Um alle nicht verwendeten Abhängigkeiten im Projekt zu entfernen, wählen Sie Nicht verwendete entfernen > Abhängigkeiten im Studio-Menüband aus, oder verwenden Sie die Tastenkombination Strg + Umschalttaste + R. Alle installierten Pakete, die keine Verweise im aktuellen Projekt enthalten, werden aus dem Projekt-Panel und der project.json-Datei entfernt.

Reparieren von Abhängigkeiten

Wenn ein in Studio geöffneter Workflow Verweise auf Pakete mit Versionen enthält, die nicht in aktuellen Studio-Feeds zur Verfügung stehen, sind die besagten Abhängigkeiten im Panel Projekt (Project) als gebrochen markiert und detaillierte Angaben stehen im Panel Ausgabe (Output) zur Verfügung.

Bei Studio können alle Abhängigkeiten massenhaft oder einzeln repariert werden. Um alle gebrochenen Abhängigkeiten zu reparieren, klicken Sie mit der rechten Maustaste auf den Knoten Abhängigkeit (Dependency) im Panel Projekt (Project) und klicken Sie auf Abhängigkeiten reparieren (Repair Dependencies).

Klicken Sie mit der rechten Maustaste auf eine gebrochene Abhängigkeit und wählen Sie Abhängigkeit auflösen (Resolve Dependency), um sie einzeln zu reparieren. Alternativ können Sie Verwalten (Manage) wählen, um das Fenster Pakete verwalten (Manage Packages) zu öffnen und Pakete zu aktualisieren.

NuGet löst gebrochene Abhängigkeiten durch Anwenden der Laufzeitregel Niedrigste anwendbare Version (Lowest Applicable Version) auf. Dies bedeutet, dass es nach der ersten anwendbaren Paketversion sucht, die höher ist als die zuvor eingestellte.

Wenn die Zielversion nicht gefunden werden kann, verwendet die Reparaturfunktion automatisch die nächst verfügbare höhere Version. Bitte beachten Sie, dass dieses Verhalten von der Feedkonfiguration abhängt.

Hinweis:

Fehlende oder ungültige Aktivitäten werden im Designer-Panel markiert, während ein Fehlerbanner zusätzliche Informationen zum Workflow und dessen ungelösten Abhängigkeitskonflikten enthält.

Festlegen von Abhängigkeitsregeln

Aktivitätspakete stehen in mehreren Versionen zur Verfügung. Dies ist der Grund, warum Sie nach dem Installieren oder Aktualisieren mit Pakete verwalten (Manage Packages) für jedes von ihnen Abhängigkeits-Ausführungszeitregeln festlegen können.

Die Ausführungszeitregel (Runtime Rule) gibt an, welche Paketversion bei Ausführungszeit installiert werden soll. Sie unterstützt die folgenden Optionen:

Die Laufzeitregel Strikt ist der Standardstatus für Abhängigkeiten, die bei der Prozesserstellung hinzugefügt werden, und für Aktivitätspakete, die über das Fenster Pakete verwalten installiert werden. Sie bedeutet, dass nur die angegebene Paketversion bei Ausführungszeit zum Ausführen des übergeordneten Prozesses verwendet wird. Die Regel Strikt ist im Panel Projekt unter Abhängigkeiten mit dem Zeichen neben der Paketversion markiert.

Die Laufzeitregel „Niedrigste gültige Version“ bedeutet, dass die nächsthöhere Version gesucht wird, um Abhängigkeiten aufzulösen, wenn das Zielpaket nicht gefunden wird. Die Regel Niedrigste gültige Version ist im Panel Projekt unter Abhängigkeiten mit dem Zeichen neben der Paketversion markiert.

When executing an automation project from Studio, the Robot downloads the specified or indicated package version it needs to execute the project, in accordance to the previously set runtime rules for each project. If the dependency used during execution has a Strict runtime rule and the exact package version was not found, an error is thrown. For more information on setting runtime rules for project dependencies check the Managing Dependencies page.

Auflösen von Abhängigkeitskonflikten

Beim Installieren von Aktivitätspaketen werden Abhängigkeits-Ausführungszeitregeln berücksichtigt, die zuvor für die besagten Pakete festgelegt waren, aber einige Konflikte zwischen Versionen können beim Automatisieren der Projekte auftreten. Sowohl das Automationsprojekt als auch die darin enthaltene Bibliothek können dieselben Aktivitätspakete aufweisen, jedoch mit anderen Versionen und Ausführungszeitregeln. Beim Erstellen löst NuGet diese Konflikte durch Auswählen der Abhängigkeiten der höchsten Ebene, die dem Projekt in der Hierarchie am nächsten kommt.

Die Auflösung der Konflikte, die auftreten können, ist weiter unten erläutert:

Das Projekt enthält in Version 1.0 ein Aktivitätspaket. Die Bibliothek wird auf das Projekt verwiesen und verwendet dasselbe Paket, jedoch mit einer höheren Version. Die Abhängigkeit v1.0 der obersten Ebene wird zur Laufzeit verwendet. Es wird eine Warnung gegeben, in der darauf hingewiesen wird, dass eine Herabstufung erkannt wurde.

The resolution of this scenario is applicable regardless of the runtime rule (Strict or Lowest Applicable Version ) previously set for the activities packages.

• Wenn Sie Ja auswählen, wird das im Projekt referenzierte Aktivitätspaket auf die in der Bibliothek verwendete Version aktualisiert.

• Wählen Sie Nein (No), wird das Fenster Pakete verwalten (Manage Packages) mit dem Fenster Projektabhängigkeiten (Project Dependencies) geöffnet.

  

Das Projekt enthält in Version 2.0 ein Aktivitätspaket. Die Bibliothek verwendet dasselbe Paket, aber mit einer niedrigeren Version und der strengen (strict) Ausführungszeitregel. Die in diesem Fall verwendete Abhängigkeit der obersten Ebene ist v2.0. Wenn das Paket im Projekt installiert wird, wird eine Warnung ausgegeben.

Das Projekt enthält in Version 2.0 ein Aktivitätspaket. Die Bibliothek verwendet dasselbe Paket, aber mit einer niedrigeren Version und der Ausführungszeitregel in niedrigster anwendbarer Version . Die in diesem Fall verwendete Abhängigkeit der obersten Ebene ist v2.0. Wenn das Paket im Projekt installiert wird, wird eine Warnung ausgegeben.

Das Projekt referenziert eine Bibliothek mit einem Aktivitätspaket der Version 1.0 und einer strengen (strict) Ausführungszeitregel. Das Projekt referenziert eine andere Bibliothek, jedoch mit einem Aktivitätenpaket der Version 2.0. Die in diesem Fall verwendete Abhängigkeit der obersten Ebene ist das Paket mit v2.0, da es die höchste Version hat. Beim Installieren des Aktivitätenpakets wird eine Warnung ausgegeben.

In diesem Konflikt referenziert das Projekt zwei Bibliotheken, die ihrerseits strenge (strict) Abhängigkeiten untereinander referenziert haben. Dieses Szenario wird nicht unterstützt. Weitere Informationen entnehmen Sie der Seite Auflösung der Abhängigkeiten (Dependency Resolution).

Abhängigkeitszyklen sind Konflikttypen, die auftreten, wenn ein Paket sich selbst referenziert. Wenn Sie Ihr Projekt UiPath nennen, erkennt Studio einen Abhängigkeitskonflikt. Dies geschieht, weil das UiPath-Paket bereits vorhanden und eine Abhängigkeit von UiPath.UIAutomation.Activities ist. Wir empfehlen, Ihrem Projekt nicht den Namen eines bereits vorhandenen Pakets zu geben, das Sie als Abhängigkeit hinzuzufügen beabsichtigen.

Derselbe Abhängigkeitszyklus ergibt sich, wenn Sie eine .xaml-Datei aus einem Ordner mit dem Namen UiPath oder einem beliebigen Namen eines vorhandenen Pakets öffnen, das Sie als Abhängigkeit hinzufügen möchten und keine project.json in diesem Ordner vorhanden ist. Wenn Sie eine .xaml-Datei öffnen, die keine zugehörige project.json-Datei aufweist, erstellt Studio eine solche und in den Tag "name" wird der Name des übergeordneten Ordners eingetragen.

Öffnen von Projekten, die mit früheren Versionen erstellt wurden

Wichtig:

Das Öffnen von Projekten, die mit Studio v2016.2 direkt in v2020.4 oder höher erstellt wurden, wird nicht unterstützt. Öffnen Sie diese Projekte zuerst mit Studio v2018.4 und dann mit v2020.4.

Beim Öffnen eines Projekts mit oder ohne Abhängigkeiten, entworfen mit einer Version vor v2018.3 (mit Ausnahme von v2016.2), werden Sie von Studio gefragt, ob eine automatische Migration durchgeführt werden soll, damit versucht werden kann, fehlende Abhängigkeiten abzurufen oder Standardabhängigkeiten hinzuzufügen.

Nach Bestätigung versucht Studio, fehlende Abhängigkeiten abzurufen, und setzt die strenge Ausführungszeitregel für die gefundenen Pakete fest. Wird die Option Reparaturabhängigkeit (Repair Dependency) im Panel Projekt (Project) verwendet, versucht Studio, die nächstbeste Paketversion zu installieren. Wird die Paketversion nicht gefunden, werden im Panel Ausgabe (Output) Warnungen eingeblendet und Sie sollten die konfigurierten Feeds im Fenster Pakete verwalten (Manage Packages) überprüfen.

Processes containing dependencies and that were built with Studio versions prior to v2018.3 continue to execute with Robot v2018.3. The runtime rule for such projects is set to Lowest Applicable Version .

Für Projekte, die mit Versionen vor v2018.3 erstellt wurden, die nie veröffentlicht wurden, sind keine Abhängigkeiten in der project.json-Datei aufgeführt. Beim Öffnen solcher Projekte werden Sie durch eine Warnung im Panel Ausgabe über fehlende Abhängigkeiten informiert. UiPath-Pakete, die lokal mit Studio erstellt wurden, werden als Abhängigkeiten mit der strengen Laufzeitregel hinzugefügt. Die aktuelle Version dieser Pakete wird automatisch festgelegt.

Wenn solche Projekte andere Pakete enthalten als die lokal mit Studio bereitgestellten, empfehlen wir Folgendes:

• Veröffentlichen des Projekts unter Verwendung der Studio-Version, in der es erstellt wurde, um so den Migrationsprozess durch das Hinzufügen von Abhängigkeiten in der project.json-Datei zu unterstützen;

• Manually installing the missing package from the Manage Packages window, after setting up the required feed;

• Using the Project Dependencies Mass Update tool to add the missing dependency to a bulk of projects.

  Hinweis:

  Workflows, die ungültige Aktivitäten enthalten, können nicht gespeichert werden. Installieren Sie die benötigte Abhängigkeit und speichern Sie dann das Projekt.

Die Aktivitätenpakete UiPath.V7.Activities, UiPath.Platform.Activities, UiPath.Framework.Activities sind veraltet. Nach Öffnen von Projekten mit UiPath.Platform.Activities und UiPath.Framework.Activities Paketen führt Studio v2018.3 eine automatische Migration durch, um die alten Versionen von Aktivitäten durch neue zu ersetzen.

Hinweis:

Workflows, die den Aktivitätsteil des Pakets UiPath.V7.Activities enthalten, können nicht migriert werden.

Für einige Fälle, in denen die Migration nicht automatisch durchgeführt wird, steht eine Übergangslösung zur Verfügung.

1. Öffnen Sie die Datei project.json mit Notepad++.

2. Entfernen Sie den Parameter "schemaVersion": "3.2"

3. Ersetzen Sie "studioVersion" durch "toolVersion".

4. Ändern Sie den Wert "toolVersion" von "18.3.xxx" auf eine frühere Version. Ändern Sie den Wert zum Beispiel von "18.3.0.958" auf "18.2.958". Speichern Sie die Datei.

5. Öffnen Sie die .xaml-Datei mit Studio ab v2018.3, um die Migration durchzuführen. Die veralteten Aktivitätenpakete werden durch neue ersetzt, wie im Abschnitt Abhängigkeiten (Dependencies) im Panel Projekt (Project) veranschaulicht.

   Hinweis:

   In some cases, .xaml files containing the packages UiPath.Platform.Activities and UiPath.Framework.Activitiescannot be automatically migrated and the workaround isn't applicable. For these situations, it is recommended to open the projects in Studio v2018.2 or lower, and replace the activities belonging to the aforementioned packages with activities contained in the UiPath.Core.Activities package. The same can be done for workflows containing activities from UiPath.V7.Activities package.

Ab Studio v2018.4.1 sind Microsoft.Activities v.1.0.1 und Microsoft.Activities.Extensions v2.0.6.9 nicht mehr im UiPathStudio.msi-Installationsprogramm enthalten.

Falls bei der Migration von Projekten, die diese Pakete als Abhängigkeiten enthalten, eine Reparatur erforderlich ist, installieren Sie die beiden Pakete aus dem Feed Official oder einem lokalen Feed. Vergewissern Sie sich vor dem Ausführen solcher Projekte, die mit Versionen vor v2018.4.1 erstellt wurden, dass die oben genannten Pakete in einem für den Roboter zugänglichen Feed verfügbar sind.

Wenn Sie eine Version vor v2018.4.1 aktualisieren, bleiben die beiden Aktivitätspakete im Feed Local.