Project Dependencies Mass Update Tool Not Functioning As Expected


We have been evaluating UiPath’s Mass Update Tool. We want to find the shortest line between creating a new library version and updating all of our automations to use the new version.

However in testing the tool, it has not completed either of the tasks it claims to perform. We are seeing no new commits to TFS and no new packages published to the orchestrator. We even tried modifying local projects and publishing them, to no avail. Yet the tool reports successful results.

I suspect a configuration issue, but I don’t know where to begin. The prerequisites for this tool are not well documented.

  • Does anyone regularly use this tool?
  • Do I require special permissions or configuration in TFS/Azure or Orchestrator to leverage this tool? I have not had issues managing dependencies for individual automations.

I have not used this feature yet myself, but I am hoping to use it very soon, so I am glad someone is taking a gamble on it.

For TFS, there is a note in the doucmentation:

There is no further note of why this is an Important step, or what the consequences are of not disconnecting before setting up the Tool, but did you follow this step when configuring the Mass Update Tool?

Hi Nick!

I chose to test on projects which I did not have mapped locally. The tool enforces this by filtering to that subset of projects: “Some remote folders are already mapped locally and will be skipped. Please check the details for extended information.” For example, I selected a folder with multiple automations in it. After filtering, only 2 were eligible because all others had been pulled down by me.

I believe the alternative is to A) disconnect all active projects from version control on your account or B) install Studio to a separate environment and perform the update from there. Though I do not believe either of these would resolve my issue given that I cannot commit to or publish unmapped projects.

It definitely seems quite odd that it noted successful operations for both, and no failed operation. I think my only other recommendation would be to see if the ‘successful’ packages ended up somewhere other than Orchestrator, like in the local packages folder and that could help pin down a mapping/configuration issue.