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.

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

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) in der Multifunktionsleiste und installieren Sie sie. 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

Um Abhängigkeiten zu einem Projekt hinzuzufügen, installieren Sie sie im Fenster Pakete verwalten. Bitte beachten Sie, dass sich die verfügbaren Pakete je nach Projektkompatibilität unterscheiden.

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. 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. Standardabhängigkeiten werden zusammen mit den Versionen angezeigt, die aktuell mit dem Projekt verknüpft sind. Um ein Projekt zu aktualisieren, klicken Sie einfach auf das Aktualisierungssymbol neben der verfügbaren Versionsnummer. Das Symbol steht neben dem Paket. Es bedeutet, dass Abhängigkeiten zum Installieren bereit sind.
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.

Beim Ausführen eines Automationsprojekts 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

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.

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.

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 im Projektbereich verwendet, versucht Studio, die nächstbeste Paketversion zu installieren. Wird die Paketversion nicht gefunden, werden im Ausgabebereich Warnungen eingeblendet und Sie sollten die konfigurierten Feeds im Fenster Pakete verwalten überprüfen.

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 Ausgabebereich ü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;
• Manuelles Installieren des fehlenden Pakets über das Fenster Pakete verwalten, nachdem der erforderliche Feed eingerichtet wurde;

• Verwenden des Massenaktualisierungstools für Projektabhängigkeiten, um die fehlende Abhängigkeit mehreren 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. Ö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 einigen Fällen können .xaml-Dateien 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.