- Release Notes
- Getting Started
- UiPath Assistant
- Installation and Upgrade
- Robot Types
- Robot Components
- Licensing
- Connecting Robots to Orchestrator
- Processes and Activities
- Logging
- Robot JavaScript SDK
- Specific Scenarios
- Troubleshooting
Custom Package Folders and Network Paths
A Package combines all parts used in an automation and it can include: Activities, Workflows, Files, Data Sources, and other components needed for running the automation. A project created in Studio is published as a Package to a location/feed from where it is later downloaded by the Robot and used to run an automation.
The following locations/feeds are configured by default in Studio:
- Orchestrator Tenant and Orchestrator Host
- Local
- Official
- Marketplace
Custom feeds can be used as well, but before setting up a custom location to publish a Package, make sure that Robots have access to it.
For more information on how feeds work and how to change them, see the Managing Activities Packages document which goes in more details on this subject.
PACKAGES_FOLDER parameter. This enables you to change the download location of your workflows and their dependencies for Studio and/or Robot.
This folder can be user specific or accessible by all users from a machine and can be used either if the Robot is installed
in Service-Mode or User-Mode.
For the Service-Mode Robot, packages are concurrently installed on all users.
C:\Packages). This is because the first User-Mode Robot which download and installs a package restricts the .XAML file access only to that user, making other User-Mode Robots on that machine unable to use the corresponding folder, or package
because of insufficient privileges.
%userProfile%\.nuget\packages.
%USERNAME% or %USERPROFILE% but needs to be escaped as follows:
-
When the setup is invoked from Command Prompt - use -
UiPathStudio.msi PACKAGES_FOLDER=C:\Some\Path\^%USERNAME^%. -
Batch scripts - use
%-UiPathStudio.msi PACKAGES_FOLDER=C:\Some\Path\^%USERNAME^%. -
For PowerShell console or scripts - no escaping is needed.
C:\packages\^%UserDomain^%.^%Username^%.
Depending on the architecture used by your company, there can be some limitations. Below you can find the most frequent use cases:
- When using a High Density environment, the path must resolve differently for different users. In this situation, the path must contain the
%USER%,%USERPROFILE%format or other user-specific path. - When High Density there is not used, the user profile does not have to be specified in the path.
- When the Robot is deployed in Service Mode and Secure XAML is used, Network Paths are not supported.
Read more about Secure XAML.
- When the Robot is deployed in Service Mode and Secure XAML is not used, there are no restrictions when using local paths.
- Only non-mapped paths are supported, e.g.
\\server\Packages. Mapped network paths such asZ:\Packagesare not supported. The reasoning consists in how the mappings are being resolved per user. In this situation, the owner of the installed files will be the computer account.
-
No restrictions on the Local or Network Path format, as the Robot uses the Attended User profile to resolve the path.
Important: Using a custom installation path might create a conflict if multiple jobs run the same project with the same installed path simultaneously and cause a race condition when writing and reading information on those files.
Read more about Secure XAML.
