Managing Reusable components

Hi All
I just wanted to discuss on how exactly are you maintaining reusable components in your projects. How do you ensure their versioning, maintenance, accessible to all team members etc.

2 Likes

The coolest way is to create a separate package and reference it dynamically within your workflow files. This is ultimately what UiPath will do in one of the next releases (I believe) so we’ve implemented it early.

@badita is that a fair comment?

Hey Richard.
That seems a good idea. But what if these components are simple reusable .xaml files (and not .nupkg).
So here we might need to leverage any VCS systems like TFS/SVN.

So when I’m saying nupkg I mean publishing the xaml files within a certain folder or sub folders which will effectively create a separate nuget package which you can reference from within other workflows. I would be avoiding using shared drives and/or repositories for containing shared components as much as possible.

Okay. So basically we need to have the xaml file published in a folder and then upload it in the Package section of the Orchestrator right?

If so, how would I invoke that package (reusable component), that is already shared in Orchestrator, in my Studio?

If you work out where the nuget package gets deployed on the machine you’ll be able to reference it dynamically :wink:

1 Like

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. :wink:

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

Update:
we’re going to stick with the symlink option - it works (for us) without writing any custom code.
See: https://forum.uipath.com/t/uipath-resuable-code-best-practice/15778/12.

1 Like

Yeah think you’re right. It doesn’t quite work as nicely as I originally thought.

Adding this to push people towards the other link. Alternative approaches are storing components on a shared drive or writing some code to force the downloading of a dependent package from source control each time a process is run.

However, this is in the uipath product backlog so we shouldn’t waste too much time coming up with a fancy workaround.

We (actually a guy in my team) came up with a nice idea this morning.

We’re going to create robot which runs each and every day on all machines. Using the Orch APIs gets the latest package name for the components folder, updates an asset containing this name so other processes can use this when invoking workflows and forces the update of the package on each machine.

Still testing - I’ll keep you all updated :slight_smile:

1 Like

hi Richard
are you including the UIpath file as a library. how do i create project reference and invoke in another project in uipatj

It’s a bit of a workaround. Basically you have two projects on a given machine.

  1. MyProcess
  2. Components

The Components project is deployed when you initially create it on the environment, however, it won’t update automatically. The API call will force the update of this project and also set an asset telling other processes what the new file path will be (i…e updated package number)

We know that the location of the files will be in ProgramData so we can derive the path for each of the subsequent Invokes.

However, it’s far from ideal so there is a strong argument for either using a shared drive OR copying new component folders each time there is an update until UiPath release the dependencies feature (can’t wait!!).

R2D2

2 Likes