If I develop a library using UiPath.UiAutomation.Activities v19.11.1 and someone tries to add the package to their project but has a different version of UiPath.UiAutomation.Activities this causes problems. It means we have to go through the administrative headache of making sure the dependency versions match before the custom activity can be used.
If the dependencies within the custom activity were scoped within that package, and not used for the entire project the custom activity package has been added to, this problem would disappear.
Thank you for your feedback @postwick. I’m sure @alexandru will know more about it, but in the meantime I’ll save your thoughts in our internal tracker so that he doesn’t miss it
We recommend to use dependencies with lowest applicable in the library so the conflict can be solved in the project. In most of the case the library will still work.
Also you can remove UiAutomation from the project, and leave it to be installed via the library dependencies. By doing so you are sure there is no conflict and you can still use the uiautomation activities.
Yes it’s true that usually everything still works. But if the library gets downgraded during the resolution, this can cause issues. As can other package version changes. But it would be 100% if the sub-packages inside libraries were scoped within that library. So if you had…
With 20.10.2 being scoped to inside the custom library, then it would use 20.10.2 and the rest of the activities in the project would use 19.11.2 of UiAutomation and then there are no conflicts, and everything is guaranteed to work as expected.