I am encountering an intermittent issue with the Read Text File activity when it is configured to use Local Path.
Context
I created a custom library that contains a workflow called REST_AffecterDemande. Inside this workflow, there is a Read Text File activity with the Local Path option enabled.
Issue
When I use this custom activity (REST_AffecterDemande) from a second robot, it sometimes fails with the following error:
REST_AJouterComment: One or more errors occurred.
(Could not find a part of the path
'C:\Users\AFCO\Documents\Projets GIT\Test_LIBCOM\GPS\API REST\REST_AjouterCommentaire\REST_Endpoint_AjouterCommentaire.txt')
Key Point – Intermittent Behavior
What makes this issue particularly confusing is that:
The error appears randomly, without any change to the Read Text File activity or the library.
It can disappear just as mysteriously, again without any modification to the workflow, activity configuration, or deployment.
Expected vs Actual Behavior
The resolved path unexpectedly includes the local project path of the robot machine:
C:\Users\AFCO\Documents\Projets GIT\Test_LIBCOM\
This is not the expected behavior.
Since the activity is configured with Local Path, it should resolve the file path relative to the library root, not the consuming robot’s local project directory.
From you scenario it looks like you are building the path dynamically, note that it can refer the path of the consuming robot if you using any local path of the library.
So in order to resolve this, you need to use library path as hardcoded or some external source referencing in the library such some text file or config file or asset etc.
If you can share some more details on how you are building path like expression or screenshot etc, then we can suggest.
As explained above, I am using the (local path) option of the activity and the harcoded path seen is the relative path inside the library :
“GPS/API REST/REST_AjouterCommentaire/REST_Endpoint_AjouterCommentaire.txt”
I tried using UiPath.Constants.Project.Location as a prefix for the file path, as suggested, but I kept encountering compilation errors. It appears that the Constants dependency is no longer available (or may be deprecated) in the Studio version I am currently using.
As an alternative, I tested prefixing the path with Environment.CurrentDirectory, and this approach seems to work consistently so far.
Would you recommend using Environment.CurrentDirectory as a standard prefix in this kind of library-related scenario, or is there a more appropriate or future-proof approach?
As per the screenshot, it looks like you are using a short path, so wherever you are consuming this library or any project, bot will look for this path in the project folder.
So, to make it stable, you need to ensure the folder structure you provided should be present in project folder, if not, make necessary changes or build dynamic path (by combining path in the screenshot) and the expected directory where your folder structure will be available (parent path).
You can create a in argument as well to pass the parent path.
However, on my Studio version, this fails to compile because UiPath.Constants does not appear to be available anymore (possibly deprecated or no longer exposed).
This resolves the file correctly at runtime and eliminates the random behavior.
Question / confirmation
Given this:
Would Environment.CurrentDirectory be considered an acceptable and supported approach to anchor file paths inside a library?
Or is the recommended design to avoid internal file resolution altogether and instead pass required paths (from the CP) as input arguments to the library?
At the moment, the intent is for the library to remain self-contained unless CP-specific paths are explicitly needed.
I would check if the file existed first with the same file path every time before reading it. That would give some clarity of the location of the file.
