At runtime, the current working directory of the compiled activities is the project current working directory (as long as there are no external resources present in the library project, such as .json, .csv, etc.). In this case, you can consume the project resources using relative path.
Hi @Cosmin_Popescu, thank you for your solution.
It works fine!
But I wanna put some resources files in the library project if I can.
Do you have any ways to get the absolute path of the process project from activities?
@ark, in this case you can add a new “path” argument to the compiled workflow and set it to
Environment.CurrentDirectory from the project using the compiled library. Then you can use the ‘path’ from within the library to access project files.
All right, I add a new arguments if there aren’t any ways.
Default value of Arguments is usefull to set
Did all in Studio 2018.3 (not beta) and after draging new library activity on workflow it reports internal errors.
Library workflow did not report any errors.
Reported errors are:
The private implementation of activity ‘’ has the following validation error:
-Type ‘GenericValue’ is not defined.
-Type ‘Image’ is not defined.
-‘forms’ is not a member of ‘Windows’.
-Type ‘Image’ is not defined.
-Value of type ‘UiPath.Core.UiElement’ cannot be converted to ‘UiPath.Core.UiElement’. (my favourite)
Any clues what went wrong ?
Looks like all imported namespaces doesnt work but only in that library because the main workflow do not report an error for i.e. generic value assign.
Can you share the library in question?
I can, but unfortunatelly in pm only for internal use.
Since I can’t find any way to view the library workflow directly, I feel the need to add some kind of documentation which can be viewed in the project where the library workflow is used. Is this possible? How about adding tool tip text to the input arguments as on built in library functions?
Is it possible to add custom icons to the activities created this way?
Also: is it possible to add a description to the input and output properties? I tried setting annotations in the arguments, thinking that would be a neat way for it to translate to a property description, but that didn’t work.
Would also be nice if a boolean input would appear as a checkbox property, right now it’s a text field.
There are two options; publish your library to Orchestrator or publish to a local folder (preferably a share network drive I assume).
Which option is the way to go? We are trying to figure out the best practices here.
I would go with the Orchestrator… as it provides a view of the libraries with it’s version history and release notes. Only downside is that the Orchestrator doesn’t seperate libraries by Org Units/Tenants.
We usually use the custom location for development purpose so that the developers won’t step on each other’s toes…with their changes in the library code.
Also my 2 cents on libraries are as below…
What I found is that there is a significant performance deterioration with the usage of libraries especially when you have to toss large objects such as dictionaries around… Loading the xamls containing the activities from library takes forever to load it…You might want to use a shared drive when you have to pass along large objects…
Also libraries doesn’t allow dynamic invokes…for example if you want to use an expression in the Invoke XAML within a workflow, library isn’t compiled…so we might want to use a shared drive for the xamls OR create a factory which will call the corresponding XAMLs based on the variable.
The other option for re-usable components is storing them in a shared drive…Downside of Re-usable components in a Shared Drive is that if there is a change and you donot want all calling processes to get impacted, you will end up maintaining versioning in shared drive for various processes which will become cumbersome along the way… So if you believe all processes can change based on the changes in shared drive, go for it.
So we need to measure the trade-offs and chose the right usage of re-usable components…
Could you explain each point in more detail (preferably with some screenshots)?
We value all user feedback and will definitely look into the performance issues you experienced, as long as we can recreate your situation. Some sample file would help here as well.
Moreover, after consulting our team, I can deliver some positive news :
- “Loading the xamls containing the activities from library takes forever to load it” - this is due to the high number of dependencies that are passed in by studio for a project and are loaded by activity initialization and is a known issue that will be addressed
- “Also libraries don’t allow dynamic invokes…for example if you want to use an expression in the Invoke XAML within a workflow” - in this case compiler identifies the case and reports it as unsupported. This is a feature that was already requested and we are looking into it.
Thank you for your feedback. I hope this is helpful for you to know the current situation
Invoking XAMLs too slow when using Libraries
Thank you for updating about the current situation… that helps… any word on the ETA for resolution??
Now we moved from shared drive reusable components to libraries and landed into the performance issues… any info on the ETA would help us decide whether we rollback or live with the libraries until the resolution…
Also where can we find the known issues list for the release…??
In terms of screenshots, the error isn’t visible in screenshots but rather in the logs…
We had encapsulated all actions on a mainframe into a library for use by various processes. We had created a process template which calls a series of common activites in a XAML which is then invoked by REFramework Main.
The time taken between the invoke to this template XAML and the actual XAML execution is observed to be 2 min.