Question
Royal Bank of Canada
CA
Last activity: 29 May 2025 13:19 EDT
Pega Runtime Project Location
I'm upgrading one of our automations from v19.1.102 to v22.1 and I've noticed a difference in the way the runtime is loading the solution that's breaking our deployment process.
We deploy the project solution .pega file manually to a production NAS alongside other config files that are referenced by the automation. I have a module in the automation that gets the location for the currently running project and then uses that to locate the config file since the build and config are deployed to the same location. This worked well in v19.
However, I'm noticing now that v22 copies the project solution .pega file from the NAS to the local "AppData\Local\Pegasystems\22.1\Projects" folder on run-time. The issue now is that, since it doesn't copy any of our other files deployed to the NAS along with it, the automation can't locate them in AppData and it fails.
This all happens when I try running our batch script to run the project:
"C:\Program Files (x86)\Pegasystems\Pega Robot Runtime v22\Pega.RobotRuntime.exe" --package "NAS_LOCATION\Solution.pega"
This also happens if I add the NAS project location to the RuntimeConfig.xml as the startup project.
What's even more interesting is that, if I manually start the Runtime and manually load the project from the same NAS using the system tray, the pega runtime doesn't copy the solution .pega file to local AppData and actually runs entirely from the NAS. In this case, there are no issues and the automation runs as expected.
I'm upgrading one of our automations from v19.1.102 to v22.1 and I've noticed a difference in the way the runtime is loading the solution that's breaking our deployment process.
We deploy the project solution .pega file manually to a production NAS alongside other config files that are referenced by the automation. I have a module in the automation that gets the location for the currently running project and then uses that to locate the config file since the build and config are deployed to the same location. This worked well in v19.
However, I'm noticing now that v22 copies the project solution .pega file from the NAS to the local "AppData\Local\Pegasystems\22.1\Projects" folder on run-time. The issue now is that, since it doesn't copy any of our other files deployed to the NAS along with it, the automation can't locate them in AppData and it fails.
This all happens when I try running our batch script to run the project:
"C:\Program Files (x86)\Pegasystems\Pega Robot Runtime v22\Pega.RobotRuntime.exe" --package "NAS_LOCATION\Solution.pega"
This also happens if I add the NAS project location to the RuntimeConfig.xml as the startup project.
What's even more interesting is that, if I manually start the Runtime and manually load the project from the same NAS using the system tray, the pega runtime doesn't copy the solution .pega file to local AppData and actually runs entirely from the NAS. In this case, there are no issues and the automation runs as expected.
Is there a way, using a similar batch script as shown above, to force Runtime to always run the project from the NAS instead of copying it locally? We don't use Robot Manager and we need to have the automation scheduled to run once a week using Windows Scheduler.
Pegasystems Inc.
US
@NicolasL8323Are these files attached to the deployment package? If so, I can show you how to access those. If not, in 19.1, how did you locate these files in your automations? If you were reading a text file for example, you'd need to provide it a path. Was that working if you simply provided it a file name without a path in 19.1?
Royal Bank of Canada
CA
@ThomasSasnett the path for the text file would have been derived from the runtime location. So the automation would get the location of the deployment package at runtime and use that location to find the text file since they were in the same folder. In 19.1, this wasn't an issue since the package was run from the NAS alongside the text file. However, in 22.1 it seems as though the package is downloaded locally, leaving behind the text file in the NAS. In this case, since the location of the package and text file are now completely different, the automation can't locate the text file.
v19.1 File locations
NAS\Location\Path\Deployment package
NAS\Location\Path\File.txt
v22.1 File locations
NAS\Location\Path\File.txt
LOCAL\Copied\Location\Path\Deployment Package
Pegasystems Inc.
US
@NicolasL832322.1 does not have the ability to discern where it is launched from since it is no longer extracted to disk. If you are launching it from a shortcut as you mentioned, you should be able to use the attached automation to read the command line which would include the arguments for the path to the package. You could extract the path from that value and use that.
What method or property were you using in 19.1 to get this location?
Royal Bank of Canada
CA
@ThomasSasnett That's a great suggestion, but limits the ability to run the automation locally without the use of the command line (during development through Robot Studio, for example).
The attached image shows how I'm currently getting the runtime location of the project:
To elaborate, it uses GetProjectPath from Runtime to get the path of the running solution, then gets its directory and concatenates the config name to construct the new config's file path. The config file is deployed separately from the project solution but stored in the same location. This happens with multiple files required for the automation, all stored in the same location. This worked in v19.1 since GetProjectPath always returned the path of the location of the project on the NAS.
However, in v22.1, this is not working when using a batch script since the Pega Runtime seems to be saving the project file locally to AppData and running it from there. In this case, when the automation uses GetProjectPath, it returns the AppData path instead of the NAS path.
@ThomasSasnett That's a great suggestion, but limits the ability to run the automation locally without the use of the command line (during development through Robot Studio, for example).
The attached image shows how I'm currently getting the runtime location of the project:
To elaborate, it uses GetProjectPath from Runtime to get the path of the running solution, then gets its directory and concatenates the config name to construct the new config's file path. The config file is deployed separately from the project solution but stored in the same location. This happens with multiple files required for the automation, all stored in the same location. This worked in v19.1 since GetProjectPath always returned the path of the location of the project on the NAS.
However, in v22.1, this is not working when using a batch script since the Pega Runtime seems to be saving the project file locally to AppData and running it from there. In this case, when the automation uses GetProjectPath, it returns the AppData path instead of the NAS path.
The most interesting thing is that if I don't use a script, and I load the project manually from the NAS through the system tray icon, v22.1 runs entirely from the NAS and works fine, just as v19.1 has. I've attached the below image of this manual load function:
So, to summarize:
- Running --package from the command line copies the project file from the NAS to AppData and the solution fails
- Manually loading the project from the system tray runs the project entirely from the NAS and the solution runs successfully
The ideal solution would be to be able to run a command line script to load the project identically to loading it manually. Is this possible? Why is there a difference in the way the project is loaded depending on the command line or system tray?
Pegasystems Inc.
US
@NicolasL8323 I believe there is a miscommunication. If your files are attached to the project, you can actually read them in v22 without a script or anything especially complicated. Here is how;
- Attach the file(s) to your project by selecting Add-->Advanced-->Deployable file from the Project tab.
- Once the file(s) is attached, you should see it appear under Miscellaneous Files on the Project tab.
- If you need access to the file on disk, you'll need to save it to a writable location. You could use %LocalAppData% as before, or you can use any location you'd prefer. You can also read it into memory as a string (assuming it isn't too large).
- Use the SavePackageFile method to save the file to disk. Use the ReadPackageFile method to read the contents as a string.
