Project dependencies in Studio refer to packages linked into a specific project, containing activities, either default or custom. Dependencies are contextual and take into consideration each project's definition, including the activities that it uses, variables, input/output arguments. Therefore, a dependency is set only if it has at least one reference in the project's definition.
All project templates available in Studio, including Process, Library, Transactional Process and Robotic Enterprise Framework, come with the following default packages:
If more need to be added, click on the Manage Packages button and install them. Installed dependencies are available only for the current project, and the list of dependencies per project is visible in the
Whenever new versions are available for the current project dependencies, the Manage Packages button from the ribbon gets an update icon .
- To manage dependencies in a project, simply right-click on the Dependencies category in the Project panel, and then click on Manage. This opens the Manage Packages window, with the Project Dependencies category. The icon shows which packages are currently installed.
- 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.
- Dependencies are installed in the project only after you click Save. Simultaneously, the versions of dependencies are updated in the
project.jsonfile belonging to the project.
To add dependencies to a project, simply search and install them as you would any activity package. For more information, check the Managing Activities Packages page.
- To remove a project dependency, simply right-click on the dependency in the Project panel.
- Select Remove Dependency, the dependency is removed from the Project panel and
Alternatively, this can be done by simply clicking on the Uninstall button available for each dependency in the Manage Packages window > Project Dependencies tab.
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 Project panel and details are made available in the Output panel.
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 Project panel, and click on Repair Dependencies.
Right-click on a broken dependency and select Resolve Dependency to repair it individually. Alternatively, you can select Manage to open the Manage Packages window and update packages.
NuGet resolves broken dependencies by applying the Lowest Applicable Version runtime rule, meaning that it searches for the first applicable package version, higher than the one previously set.
Activity packages are available in multiple versions, which is why upon installing or updating them using the Manage Packages window, you can set dependency runtime rules for each of them.
The Runtime Rule specifies which package version to install at runtime. It features two available options.
The Strict runtime rule is the default state dependencies added upon process creation. 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 Project 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 Project panel, under Dependencies by the sign next to the package version.
The installation of activities packages takes into consideration dependency runtime rules previously set for said packages, but some conflicts between versions might occur when automating the projects. Both the automation project and the library it contains might have the same activities package, but with different versions and runtime rules. At design time, NuGet resolves such conflicts by choosing the top level dependency, which is the closest to the project in the hierarchy.
The resolution of conflicts that might occur is explained below:
If the project contains an activities package with the version 1.0. The library is referenced to the project and uses the same pack, but with a higher version. The top level dependency v1.0 is used at runtime. A warning is given, mentioning the affected activities package.
The resolution of this scenario is applicable regardless of the runtime rule (Strict or Lowest Applicable Version ) previously set for the activities packages.
- If you choose Yes, NuGet attempts to resolve the dependency conflict, but this could result in unpredictable behavior at design time and runtime.
- If you choose No, the Manage Packages window is opened in the Project Dependencies tab.
The project contains an activities package with the version 2.0. The library uses the same pack, but with a lower version and the Strict runtime rule. The top level dependency used in this case is v2.0 and a warning is given when the package is installed in the project.
The project contains an activities package with the version 2.0. The library uses the same pack, but with a lower version and the Lowest Applicable Version runtime rule. The top level dependency used in this case is v2.0 and a warning is given when the package is installed in the project.
The project references a library with an activities package version 1.0 and Strict runtime rule. The project references another library, but with an activities package version 2.0. The top level dependency in this case is the pack with v2.0, since it has the highest version. A warning is given when the activities package is installed.
In this conflict the project references two libraries, which in turn have Strict dependencies referenced among them. This scenario isn't supported. For detailed information, check the Dependency Resolution page.
Dependency cycles are types of conflicts that occur when a package references itself. If you name your project UiPath, Studio detects a dependency conflict. This happens because the UiPath package already exists and is a dependency to
UiPath.UIAutomation.Activities. It is recommended to avoid naming your project with the name of an already existing package that you intend to add as a dependency.
The same dependency cycle occurs if you open a
.xaml file from a folder named UiPath or any name of an existing package that you intend to add as a dependency, and there is no
project.json in that folder. When you open a
.xaml file that doesn’t have an associated
project.json file, Studio creates one and the
"name" tag is populated with the name of the parent folder.
When opening a project with or without dependencies, designed with a version prior to v2018.3, Studio asks you if an automatic migration shall be performed, so that it may attempt to retrieve missing dependencies or add default ones.
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 Project 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.
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 .
Projects created with versions prior to v2018.3 that were never published don't have dependencies listed in the
project.json file. When opening such projects, an alert in the Output panel notifies you of missing dependencies. UiPath packages delivered locally with Studio are added as dependencies with the Strict runtime rule. The latest version of such packages is automatically set.
If such projects contain packages other than those delivered with Studio locally, we recommend:
- Publishing the project using the Studio version in which it was created, thus aiding the migration process by adding dependencies in the
- Manually installing the missing package from the Manage Packages window, after setting up the required feed.
Workflows containing invalid activities cannot be saved. Install the needed dependency and then save the project.
UiPath.Framework.Activities have been deprecated. Upon opening projects with
UiPath.Framework.Activities packages, Studio v2018.3 or above attempts to perform an automatic migration to replace the old versions of activities with new ones.
Workflows containing activities part of
UiPath.V7.Activities package cannot be migrated.
A workaround is available for some cases in which the migration isn't automatically performed.
- Open the
project.jsonfile with Notepad++.
- Remove the
- Change the
"18.3.xxx"to a previous version. For example, change the value from
"18.2.958". Save the file.
- Open the
.xamlfile 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 Project panel.
In some cases,
.xaml files containing the packages
UiPath.Framework.Activities cannot 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