Verwalten von Abhängigkeiten

Verwalten von Projektabhängigkeiten in Studio, einschließlich Hinzufügen, Aktualisieren und Entfernen von Aktivitätspaketen, die mit einem Automatisierungsprojekt verknüpft sind.

Projektabhängigkeiten in Studio beziehen sich auf Pakete, die in einem bestimmten Projekt verknüpft sind. Diese Pakete enthalten entweder standardmäßige oder benutzerdefinierte Aktivitäten.

Abhängigkeiten sind kontextabhängig und berücksichtigen:

• Aktivitäten, die das Projekt verwendet
• Projektvariablen
• Eingabe- und Ausgabeargumente

Eine Abhängigkeit wird nur festgelegt, wenn sie mindestens einen Verweis in der Definition des Projekts hat.

Standardabhängige und benutzerdefinierte Abhängigkeiten

Die Standardabhängigkeiten für ein Projekt unterscheiden sich je nach Projekttyp, Kompatibilität oder Vorlage, die zum Erstellen des Projekts verwendet wurde.

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.

The Explorer panel displays the activities packages installed in the automation project, together with their sub dependencies, runtime rules, requested, and resolved versions. The project compatibility is displayed in the Dependencies node.

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

Um Abhängigkeiten zu einem Projekt hinzuzufügen, installieren Sie sie über das Fenster Pakete verwalten. Bitte beachten Sie, dass sich die verfügbaren Pakete aufgrund der Projektkompatibilität unterscheiden. Sie können ein Paket auch installieren, indem Sie eine der darin enthaltenen Aktivitäten einem Projekt über die Kategorie Verfügbar des Aktivitätenbereichs oder die Suchleiste Aktivität hinzufügen.

Immer wenn neue Versionen für die aktuellen Projektabhängigkeiten zur Verfügung stehen, hat die Schaltfläche Pakete verwalten (Manage Packages) der Multifunktionsleiste ein Aktualisierungssymbol.

1. To manage dependencies in a project, open the context menu for the Dependencies category in the Explorer panel, and then select Manage. This opens the Manage Packages window, with the Project Dependencies category. The icon shows which packages are currently installed.

   

2. Default dependencies are displayed, together with the versions that are currently linked to the project. To update a package, select 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 Auswahl im Projekt installiert. Gleichzeitig werden die Versionen von Abhängigkeiten in der Datei project.json aktualisiert, die zu dem Projekt gehört.

Ergebnis

Die ausgewählten Abhängigkeiten werden dem Projekt hinzugefügt oder im Projekt aktualisiert. Paketversionen werden in der Datei project.json aktualisiert.

Entfernen von Abhängigkeiten

• To remove a project dependency, right-click the dependency in the Explorer panel, and then select Remove Dependency. The dependency is removed from the Explorer panel and project.json file. Alternatively, you can go to Manage Packages > Project Dependencies, select the dependency to remove, and then click Uninstall.
• To remove all unused dependencies in the project, select Remove Unused > Dependencies in the Studio ribbon, or use the Ctrl + Shift + R keyboard shortcut. All the installed packages that have no references in the current project are removed from the Explorer panel and project.json file.

Reparieren von Abhängigkeiten

If a workflow opened in Studio has references to packages with versions that aren’t available in current Studio feeds, said dependencies are marked as broken in the Explorer panel and details are made available in the Output panel.

Reparieren von Abhängigkeiten

Studio allows for all dependencies to be repaired in bulk or individually. To repair all broken dependencies, right-click on the Dependency node in the Explorer panel, and click on 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.

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:

The Strict runtime rule is the default state for dependencies added upon process creation, and for activities packages installed from the Manage Packages window. It means that only the specified version of the package is used at runtime to execute the parent process. The Strict rule is marked in the Explorer panel, under Dependencies by the sign next to the package version.

The Lowest Applicable Version runtime rule means that if the target package isn’t found, the next higher version is searched in order to resolve dependencies. The Lowest Applicable Version rule is marked in the Explorer panel, under Dependencies by the sign next to the package version.

Ausführen mit Abhängigkeitsregeln

Beim Ausführen eines Automatisierungsprojekts aus Studio lädt der Roboter die spezifizierte oder angegebene Paketversion herunter, die er braucht, um das Projekt gemäß den zuvor festgesetzten Ausführungszeitregeln für jedes Projekt auszuführen. Hat die beim Ausführen verwendete Abhängigkeit eine strenge (Strict) Ausführungszeitregel und die genaue Paketversion wurde nicht gefunden, wird ein Fehler ausgegeben. Um weitere Informationen zum Festsetzen von Ausführungszeitregeln für Projektabhängigkeiten zu erhalten, gehen Sie auf die Seite Verwalten von Abhängigkeiten (Managing Dependencies).

Auflösen von Abhängigkeitskonflikten

Bei der Installation von Aktivitätspaketen werden zuvor festgelegte Regeln für die Abhängigkeitsausführungszeit berücksichtigt. Beim Automatisieren von Projekten können jedoch Konflikte zwischen Versionen auftreten.

Sowohl das Automatisierungsprojekt als auch seine Bibliotheken können dasselbe Aktivitätspaket mit unterschiedlichen Versionen und Ausführungszeitregeln enthalten. Zur Entwurfszeit löst NuGet solche Konflikte, indem die Abhängigkeit der obersten Ebene ausgewählt wird – diejenige, die dem Projekt in der Hierarchie am nächsten ist.

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.

Die Auflösung dieses Szenarios ist ungeachtet der Ausführungszeitregel anwendbar (streng (Strict) oder (Niedrigste anwendbare Version (Lowest Applicable Version ), die zuvor für die Aktivitätspakete festgelegt war.

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

Upon confirmation, Studio attempts to retrieve missing dependencies and sets the Strict runtime rule for the packages that it finds. When using the Repair Dependency option in the Explorer panel, Studio attempts to install the next best package version. If the package version is not found, alerts are shown in the Output panel and you should check the configured feeds in the Manage Packages window.

Abhängigkeiten für alte Projekte

Prozesse, die Abhängigkeiten enthalten und die mit Studio-Versionen vor v2018.3 erstellt wurden, werden weiterhin mit Robot v2018.3 ausgeführt. Die Ausführungszeitregel für diese Projekte ist auf Niedrigste anwendbare Version festgelegt.

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;
• Manuelle Installation des fehlenden Pakets aus dem Fenster Pakete verwalten nach dem Einrichten des erforderlichen Feeds;
• Verwenden Sie das Tool zur Massenaktualisierung von Projektabhängigkeiten, um die fehlende Abhängigkeit einer Vielzahl von Projekten hinzuzufügen.
  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. Open the .xaml file with Studio v2018.3 or above for the migration to be performed. The deprecated activities packages are replaced with new ones, as illustrated in the Dependencies section of the Explorer panel.
   Hinweis:

   In einigen Fällen können .xaml-Daten mit den Paketen UiPath.Platform.Activities und UiPath.Framework.Activities nicht automatisch migriert werden und die provisorische Lösung ist nicht anwendbar. Für diese Situationen empfehlen wir, die Projekte mit einer Studioversion bis höchstens v2018.2 zu öffnen und die zu den vorgenannten Paketen gehörenden Aktivitäten durch die im Paket UiPath.Core.Activities enthaltenen Aktivitäten zu ersetzen. Dasselbe ist bei Workflows möglich, die Aktivitäten von Paket UiPath.V7.Activities enthalten.

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.