We are seeking your advice on a particular use case and would greatly appreciate input from anyone who has tackled a similar challenge in their automation journey.
Currently, we are using an application whose Login page is set to undergo a complete redesign in the coming months. We have multiple tests and process automation bots relying on the existing login page, and once the upgrade is implemented, these will fail due to the UI changes. (Note: We are keeping Healing Agent out of scope for this project for some reasons)
To address this, our plan is to develop a library that will be integrated across all our test and process automation bots. This approach allows us to modify the library just once to accommodate the new Login UI, ensuring continuity even after the UI changes.
However, there is a complication: after updating the library with the new UI and deploying it to the orchestrator, we still need to manually open each XAML file for every test and process automation to update the library package so they can utilize the new UI.
Here is the specific use case: Is there a method to enable the libraries to auto-update, thus eliminating the need to manually access each XAML file for our tests and process automation bots just to update the library package for the new UI?
Please let me know if you require additional details regarding this use case.
There is no way to do this automatically, but there’s a fairly simple way to do this manually. What you need to do is publish the new library with the same version as the existing library. In order to do this, you must:
Delete the package from Orchestrator
Delete the package file from all robot servers in all folders (default storage is per-robot so you have to go to "C:\Users\robotusername\.nuget\Packages for each robot user on each server - unless you have changed from the default package storage location in which case you’d delete it from wherever you are storing packages)
Publish the new library package with the same version as the package you deleted
This way all your robots are “tricked” into re-downloading the library package from Orchestrator which is actually your new library.
The danger to this is you didn’t actually test any of those automations with the new library, and failures could result due to conflicts with other dependencies in those projects.
You were correct using the tool only updates the project.json file in your project folders. It does not update the published package in Orchestrator.
I tried the workaround given by you and this seems to be working file and has less manual work as compared to opening each file and updating the package.
