Dependencies should be scoped to avoid version conflicts in custom activities (libraries)

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 :slight_smile:

Thank you for your feedback @postwick.

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.

1 Like

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…

– UiAutomation 19.11.2
– Custom library
------ UiAutomation 20.10.2

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.