Managing Reusable components

[Garth_Ormsby]

Hi Richard,

I had a crack at your suggestion - I added an InvokeWorkflowFile argument driven Xaml into a project and published it via Studio. The package landed in (say)

%ALLUSERSPROFILE%\UiPath\Packages\Acme.ReusableActivity.<version>.nupkg

There was no sign of the package extract under %ALLUSERSPROFILE%\UiPath\Projects, until I “updated” it via UiRobot and found it here: (in hindsight, that makes sense: publish = make package for download)

%ALLUSERSPROFILE%\UiPath\Projects\Acme.ReusableActivity.<version>\lib\net45\MySharedActivity.xaml

I can live with having to publish+update shared Xamls before reuse during dev, but the inclusion of in the path makes referencing this file path feel risky. I understand why the version has to be in the path, and it can be argued that I should be forced to change the version number explicitly when I want to “upgrade” but… it’s also a PITA.

To pursue this method of reuse, I’d end up coding a Acme.Activities.InvokeWorkflowFile that calls a function - say GetProjectXamlFilePath("MyCompany.MySharedActivity", "1.0.*") that will locate the latest version of the Xaml matching the version wildcard.

Too much fuss for today, so I’m going to retreat to the symlink option as outlined here:
https://forum.uipath.com/t/uipath-resuable-code-best-practice/15778/6

Unless you can steer my thinking to a simpler/cheaper option?

Regards
Garth