In order to execute an automation project, the Robot needs access to project-associated activities. There are four default activity feeds: Local, Orchestrator, Official, and Go!. The interaction between them and your Robot depends on criteria such as the availability and state of the feeds, the connection to Orchestrator, package signing, and the runtime rules set in Studio.
The following situations can occur:
- If you choose to install the local Studio feed, the
%ProgramFiles(x86)%\UiPath\Studio\Packagesfolder is created. It contains the activity packages that are officially supported by UiPath at install time. The feed is enabled by default.
- If you choose not to install the local Studio feed, the
%ProgramFiles(x86)%\UiPath\Studio\Packagesfolder is created, however it only contains the packs that are added as default dependencies to a new project:
- When you connect the Robot to Orchestrator, a NuGet feed is provided by Orchestrator. It contains the activity packages that are officially supported by UiPath. The feed is enabled by default and is dependent on your storage settings.
The use of copy-paste commands in the packages-dedicated folder is not supported for composite repositories.
Activity packs are stored in the host feed even if you configured your libraries to be segregated at tenant level. Details about libraries feeds here.
- If the Robot is not connected to Orchestrator, nor does it find the required activities in the local feed, a MyGet feed,
https://www.myget.org/F/workflow/, can be used. This is the official online UiPath feed from which the Package Manager in Studio also retrieves its activities. It contains the activity packages that are officially supported by UiPath. This feed is disabled by default. To enable it, go to Settings > Manage Sources in Studio, and select the corresponding check box.
More details about managing activity packages in our Studio guide here.
Feeds can be secured either through an API key or basic authentication credentials.
Due to a NuGet limitation, in environments under a heavy load, activity packages are slow to unpack if you manually copy several packs in the local feed. It is recommended that you upload the activities via NuGet.
When you start a job, the Robot searches for the required activity packages in all available sources and retrieves them from the one with the best response time. Due to activity packages having multiple versions, this process also takes into account the runtime rules selected for the packages in Studio, as follows:
- If you selected Strict as a runtime rule, the Robot searches for the exact version specified for that package. For example, if you set the Version field to 2.5.0, and the Runtime Rule field to Strict, the Robot only searches for version 2.5.0 of that package. If the version is not found in any of the existing sources, an error is thrown.
- If you selected Lowest Applicable Version as a runtime rule, the Robot searches for the specified version or above. For example, if you set the Version field to 2.5.0, and the Runtime Rule field to Lowest Applicable Version, the Robot searches any version starting with 2.5.0, say 2.5.0, 2.5.1, 2.5.2 and so on. If none of the applicable versions are found in any of the existing sources, an error is thrown.
More details about project dependencies in our Studio guide here.
If you enforced the use of signed packages, you cannot retrieve activity packs that are not signed, regardless of whether or not they are found in your feeds. More details about signing packages in our Studio guide here.
The following are the officially supported activities packages installed with Studio and Robot, if selected, and Orchestrator:
- UiPath - Dependency for the
- UiPath.Vision - Dependency for the
- UiPath.Framework.Activities - Required for legacy process compatibility
- UiPath.CefSharpBundle - Dependency for
C#process design in Studio
Updated 4 months ago