Question
RBC
CA
Last activity: 28 Oct 2025 12:10 EDT
GetProjectPath returns inconsistent results
I have a library of automations that are used in numerous RPA solutions. In one of the main routines, the function GetProjectPath is used to get the location of the running automation. When the automation is included directly into a solution it returns the correct path and project name.
Attempting to turn the library into an Asset, the function returns the "Asset" project name, instead of the solution's directly. Is there a way to consistently get the project's path/name?
attached is samples of the differing behavior.
Pegasystems Inc.
US
@RobIsTheName Given that project files are no longer extracted to disk in 22.1 or R25, is there still a need for this path? You can get the project name from the static method GetProjectName. Would that be sufficient? I believe GetProjectPath would only return the Asset path if called from within the Asset. If you called it from your project, it should return the value from the project itself.
RBC
CA
@ThomasSasnett Both GetProjectPath and GetProjectName suffer from the same error. The reason to pick up the name is that data for those solutions are stored on central server. To load/save the correct parm/settings, the project name is used as a reference. The reason we did this was to isolate all config /data settings from the code/application. It was suppose to future proof us, not matter the version, file structure, etc.. so long as we keep the project/solution name unique, we can store data based on that name from deployed solution.
However it now seems that if the call is in an asset, it points to the shared asset project, which breaks our projects being ported to 22, and my understanding of Runtime functions. At runtime, i'm running a solution that includes an asset (library) of code. runtime functions should reflect runtime project, not the internal library(s) . Shouldn't it?
Pegasystems Inc.
US
@RobIsTheName GetProjectName (or Path) will return the name of the project that you execute that method from. That is how they behave (when run from Runtime anyway). There are differences when run from Studio, but Runtime behavior is really the most important part. If you want your Assets to know the name of the project that is calling them, my suggestion would be to initialize them with the parent project name when they are started. Create an Initialize automation where your constant values are passed to the Asset for use during its lifetime.
RBC
CA
@ThomasSasnett Now I'm seeing another oddity, when the solution is deployed, and executed using the commandline utility, the function GetProjectPath doesn't return the path of the project, but instead returns a made up path that includes wherever the command was executed from, with an attached subdirectory called "asset".
ex:
command executed: C:\foo>"c:\Pegasystems\Pega Robot Studio v22\Pega.RobotRuntime.exe" -p c:\test\MyAsset.pega
GetProjectPath returned: C:\foo\Assets\SupportLibraryF6.pegaAsset
Can't trust the function the way it is...
Pegasystems Inc.
US
@RobIsTheNameI am attaching my test solution and Asset. I do not believe you need the project path anymore (since no files are really extracted). Can you please clarify what use you'd have for that method? That being said, in 22.1, it will download the package to the %LocalAppData%\Pegasystems folder and when you run from Runtime, the ProjectPath of the main project will reflect that folder. Running it from Studio will be different and will reflect the folder where the project exists. The project name will always be consistent though depending on what level you execute it from.
RBC
CA
@ThomasSasnett Thanks for the example project. Unfortunately it confirms the behavior of the two functions and how it differs from 19.1.. The main reason we try to get the projectname in an asset project vs the caller, is to simplify the start up logic of our solutions. In 19.1, solutions that included our support library benefited from have the library initialize all environmental constructs based on the solution name. No coding was required by any developer to enable, and start a bot, with a bunch of functionality contained in the central library.
Now we're going to have to force developers to add some code to each solution as they upgrade solutions, and remember to add during new projects. It may not sound like a big item to add a couple lines of code to each automation, but it adds up over time, and allows coders to get "creative", introducing errors in to projects that would otherwise be in one place, never changing... o'well, we'll need to make do. thanks for you efforts/explanation Thomas...