- Release Notes
- Getting Started
- Setup and Configuration
- Automation Projects
- Dependencies
- About Dependencies
- Managing Dependencies
- Missing or Invalid Activities
- Types of Workflows
- Control Flow
- File Comparison
- Automation Best Practices
- Source Control Integration
- Debugging
- Logging
- The Diagnostic Tool
- Workflow Analyzer
- About Workflow Analyzer
- ST-NMG-001 - Variables Naming Convention
- ST-NMG-002 - Arguments Naming Convention
- ST-NMG-004 - Display Name Duplication
- ST-NMG-005 - Variable Overrides Variable
- ST-NMG-006 - Variable Overrides Argument
- ST-NMG-008 - Variable Length Exceeded
- ST-NMG-009 - Prefix Datatable Variables
- ST-NMG-011 - Prefix Datatable Arguments
- ST-NMG-012 - Argument Default Values
- ST-NMG-016 - Argument Length Exceeded
- ST-NMG-017 - Class name matches default namespace
- ST-DBP-002 - High Arguments Count
- ST-DBP-003 - Empty Catch Block
- ST-DBP-007 - Multiple Flowchart Layers
- ST-DPB-010 - Multiple instances of [Workflow] or [Test Case]
- ST-DBP-020 - Undefined Output Properties
- ST-DBP-021 - Hardcoded Timeout
- ST-DBP-023 - Empty Workflow
- ST-DBP-024 - Persistence Activity Check
- ST-DBP-025 - Variables Serialization Prerequisite
- ST-DBP-026 - Delay Activity Usage
- ST-DBP-027 - Persistence Best Practice
- ST-DBP-028 - Arguments Serialization Prerequisite
- ST-USG-005 - Hardcoded Activity Arguments
- ST-USG-009 - Unused Variables
- ST-USG-010 - Unused Dependencies
- ST-USG-014 - Package Restrictions
- ST-USG-020 - Minimum Log Messages
- ST-USG-024 - Unused Saved for Later
- ST-USG-025 - Saved Value Misuse
- ST-USG-026 - Activity Restrictions
- ST-USG-027 - Required Packages
- ST-USG-028 - Restrict Invoke File Templates
- ST-USG-032 - Required Tags
- ST-USG-034 - Automation Hub URL
- Variables
- Arguments
- Imported Namespaces
- Coded automations
- Introduction
- Registering custom services
- Before and After contexts
- Generating code
- Generating coded test case from manual test cases
- Trigger-based Attended Automation
- Recording
- UI Elements
- Selectors
- Object Repository
- Data Scraping
- Image and Text Automation
- Automating Citrix Technologies
- RDP Automation
- VMware Horizon Automation
- Salesforce Automation
- SAP Automation
- macOS UI Automation
- The ScreenScrapeJavaSupport Tool
- The WebDriver Protocol
- Extensions
- About extensions
- SetupExtensions tool
- UiPathRemoteRuntime.exe is not running in the remote session
- UiPath Remote Runtime blocks Citrix session from being closed
- UiPath Remote Runtime causes memory leak
- UiPath.UIAutomation.Activities packages and UiPath Remote Runtime versions mismatch
- The required UiPath extension is not installed on the remote machine
- Screen resolution settings
- Chrome Group Policies
- Cannot communicate with the browser
- Chrome extension is removed automatically
- The extension may have been corrupted
- Check if the extension for Chrome is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and Incognito mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Chrome
- Chrome Extension on Mac
- Edge Group Policies
- Cannot communicate with the browser
- Edge extension is removed automatically
- The extension may have been corrupted
- Check if the Extension for Microsoft Edge is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and InPrivate mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Edge
- Extension for Safari
- Extension for VMware Horizon
- Extension for Amazon WorkSpaces
- SAP Solution Manager plugin
- Excel Add-in
- Test Suite - Studio
- Troubleshooting
Managing Dependencies
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.
In Studio, the default dependencies for a project differ depending on the project type, compatibility, or template used to create the project.
UiPath.System.Activities
, UiPath.ComplexScenarios.Activities
, UiPath.Excel.Activities
, UiPath.Mail.Activities
, UiPath.Presentations.Activities
,UiPath.UIAutomation.Activities
, and UiPath.Word.Activities
.
project.json
file.
The Project 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.
Hover over a dependency to view requested and resolved versions. Contextual actions like Manage, Repair or Remove Dependency are available only for dependencies and not their subpackages.
- Red - The dependency was not found.
- Orange - A subpackage was not found.
- Gray - The dependency is unresolved.
- Faded Blue - The resolved version is higher than the requested version.
- Strong Blue - There is an exact match between the requested version and the resolved version.
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 .
-
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.json
file belonging to the project.
-
To remove a project dependency, right-click the dependency in the Project panel, and then select Remove Dependency. The dependency is removed from the Project 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 Project panel and
project.json
file.
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.
If the target version cannot be found, the repair function automatically uses the next available higher version. Please note that this behavior depends on the feed configuration.
Activity packages are available in multiple versions, which is why upon installing or updating them using the Manage Packages, 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 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 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.
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.
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:
The project contains an activities package with 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 that a downgrade was detected.
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, the activities package referenced in the project is upgraded to the version used in the library.
-
If you choose No, the Manage Packages window is opened with the Project Dependencies window.
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.
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.
.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 (except for v2016.2), 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.
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
project.json
file; - 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.
Note: Workflows containing invalid activities cannot be saved. Install the needed dependency and then save the project.
UiPath.V7.Activities
, UiPath.Platform.Activities
, UiPath.Framework.Activities
have been deprecated. Upon opening projects with UiPath.Platform.Activities
and 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.
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.json
file with Notepad++. - Remove the
"schemaVersion": "3.2"
parameter. - Replace
"studioVersion"
with"toolVersion"
. - Change the
"toolVersion"
value from"18.3.xxx"
to a previous version. For example, change the value from"18.3.0.958"
to"18.2.958"
. Save the file. -
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 Project panel.Note: In some cases,.xaml
files containing the packagesUiPath.Platform.Activities
andUiPath.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 theUiPath.Core.Activities
package. The same can be done for workflows containing activities fromUiPath.V7.Activities
package.
UiPathStudio.msi
installer.
In case repairing is needed when migrating projects containing these packs as dependencies, install the two packages from the Official feed or a local feed. Before executing such projects created with versions prior to v2018.4.1, make sure that the aforementioned packages are available in a feed accessible by the Robot.
If you upgrade from a version prior to v2018.4.1, the two activities packages remain on the Local feed.