25.10.16

Veröffentlichungsdatum: 18. Mai 2026

Neuigkeiten

Überschreiben Sie die Stammkategorie der Aktivitäten beim Packen einer Bibliothek

Wenn Sie ein Bibliotheksprojekt packen, erhält jede Aktivität, die vom resultierenden Paket verfügbar gemacht wird, ein Stammkategoriepräfix. Standardmäßig ist dieses Präfix der Name des Bibliotheksprojekts. Mit dem neuen --activitiesRootCategory Parameter können Sie ihn überschreiben, ohne das Projekt umzubenennen.

uipcli package pack "C:\projects\MyLibrary\project.json" -o "C:\Output" --activitiesRootCategory "MyCompany.Finance.Invoicing"

Aktivitäten im resultierenden .nupkg werden unter MyCompany.Finance.Invoicing im Studio-Aktivitätenbereich eines jeden Projekts angezeigt, das die Bibliothek installiert.

Der Parameter hat nur beim Packen eines Bibliotheksprojekts Auswirkungen. Wird für die Ausgabetypen Process, Tests und Objects ignoriert. Wenn er weggelassen wird, ist das Verhalten unverändert: Die Stammkategorie greift auf den Bibliotheksprojektnamen zurück und entspricht dem, was das Dialogfeld „Bibliotheksveröffentlichung“ in Studio erzeugt.

Analyse und Validierung während des Packens überspringen

Workflow-Analyse und Projektvalidierung werden automatisch als Teil von package pack ausgeführt. Mit zwei neuen Flags können Sie jeden Schritt deaktivieren:

• --skipAnalyze – Die Ausführung der Workflow-Analyse während des Packschritts überspringen.
• --skipValidate – Überspringen Sie den Schritt Projektvalidierung während des Packschritts.

uipcli package pack "C:\projects\MyProject\project.json" -o "C:\Output" --skipAnalyze --skipValidate

Verwenden Sie diese Flags, wenn:

• Ihre Pipeline wird bereits package analyze ausgeführt oder validiert das Projekt in einer früheren Phase (z. B. bei einer Prüfung vor der Zusammenführung), und Sie möchten die gleichen Kosten am pack nicht erneut bezahlen.
• Sie erstellen ein schnelles Paket für das lokale Debugging und benötigen nur das Artefakt.

Für Release-Pipelines wird weiterhin empfohlen, beide Schritte aktiviert zu lassen.

Nur Abhängigkeiten auflösen von --nugetConfigFilePath

Das neue Flag --excludeConfiguredSources schließt die integrierten Feeds von UiPath und die NuGet-Konfiguration auf Benutzer- und Maschinenebene auf dem Host aus, auf dem die CLI ausgeführt wird (normalerweise %AppData%\NuGet\NuGet.Config und %ProgramFiles(x86)%\NuGet\Config). Die CLI löst Pakete nur aus den Feeds auf, die in der nuget.config -Datei definiert sind, die Sie über --nugetConfigFilePath übergeben.

uipcli package pack "C:\projects\MyProject\project.json" -o "C:\Output" \
  --nugetConfigFilePath "C:\ci\nuget.config" \
  --excludeConfiguredSources

Verwenden Sie dieses Flag, wenn:

• Sie möchten hermetische, reproduzierbare Builds, bei denen nur die Feeds abgefragt werden, die Sie in der Versionskontrolle deklarieren.
• Ein gemeinsam genutzter Build-Agent verfügt über Feeds auf Maschinenebene, die nicht in bestimmte Pipelines eingebunden werden sollen.
• Sie debuggen „funktioniert bei Agent A, schlägt bei Agent B fehl“-Probleme, die durch eine unterschiedliche NuGet-Konfiguration auf Hostebene verursacht werden.

Wenn Sie uipcli mit einer Konfigurationsdatei ausführen, legen Sie "excludeConfiguredSources": true fest.

Stellen Sie sicher, dass Ihre nuget.config jeden Feed deklariert, den das Projekt benötigt – einschließlich aller UiPath-Feed-Äquivalente –, da keine andere Quelle konsultiert wird, wenn dieses Flag festgelegt ist.

Verbesserte Leistung unter Linux und macOS für analyseintensive Projekte

Beim Packen eines Projekts, das eine hohe Anzahl von Workflow-Analyse-Warnungen unter Linux oder macOS erzeugt, dauerte die CLI zuvor mehrere Minuten, um Analysemeldungen nach Abschluss der eigentlichen Kompilierung abzuführen. Der interne Kommunikationskanal zwischen der CLI und dem SolutionPackager wurde auf eine Named-Pipe-/Unix-Domain-Transport-Socket umgestellt, wodurch dieser Engpass entfernt wurde.

Es ist keine Benutzeraktion erforderlich – Pakete, die unter Linux mehr als 15 Minuten für die Verbose-Ausgabe gedauert haben, sind jetzt in Sekunden nach Abschluss der Kompilierung abgeschlossen. Das Windows-Verhalten ist unverändert.

Schnellere Wiederherstellung – keine doppelten NuGet-Downloads mehr in einem einzigen Durchlauf

Wenn ein einzelner CLI-Aufruf mehrere Wiederherstellungsschritte ausgelöst hat (z. B. ein pack , das validiert und dann verpackt wird, oder ein solution pack , der jedes Projekt wiederherstellt), können dieselben NuGet-Pakete mehrmals heruntergeladen werden, da das HTTP-Cache-Fenster bereits vorhanden war abgelaufen zwischen Schritten. Die CLI speichert jetzt bereits heruntergeladene Pakete für 15 Minuten innerhalb eines einzigen Laufs zwischengespeichert, sodass nachfolgende Wiederherstellungsschritte die lokalen Kopien wiederverwenden, anstatt erneut aus dem Feed abzurufen.

Es ist keine Benutzeraktion erforderlich – Projekte mit vielen Abhängigkeiten erfahren eine merkliche Beschleunigung bei Befehlen, die eine NuGet-Wiederherstellung durchführen.

Version und Runtime, die beim Start ausgegeben werden

Jeder CLI-Aufruf gibt jetzt ein Banner als erste Ausgabezeile aus:

uipcli: version 25.10.16, running on .NET 8.0.x

Dadurch sind Supportprotokolle selbstbeschreibend – es besteht keine Mehrdeutigkeit darüber, welcher CLI-Build oder welche Runtime eine bestimmte Protokolldatei erzeugt hat.

Aktualisierte Dokumentation

• Packen von Projekten in ein Paket
• Wiederherstellen von Automatisierungsabhängigkeiten
• Analysieren eines Projekts
• Testen eines Pakets oder Ausführen eines Testsatzes
• Verwalten von NuGet-Feeds