Days before today I had the following reported error in the PRODUCTION environment:
The procedure for the deployment of the robots in the Production environment are Upload the package to the Orchestrator, create the Process, Triggers and finally, we open the UiRobot, download the package in the Local and Execute the robot to discard any error of environment.
It is just in this last step that the error appeared (attached image).
We make multiple validations:
Validation of permissions in the VM where the robots are executed (everything was OK).
Validation of permissions at service level (everything was OK).
Validation of uipath ports (everything was OK).
Validation of the url: www.myget.org (everything was OK).
We detected that some packages were not downloaded in the path: C:\Users\XXX.nuget\packages. Specifically the package shown in the image (not found). The action we took was to copy packages from other environments and paste them but it still didn’t work. (Discard this action).
Successful solution:
Finally we validated that UiPath Studio was installed in the Production environment, so we performed the following successful steps that solved the problem:
The project folder (where Main.xalm is located) was copied to the Production environment.
The project was opened with UiPath Studio.
When opening UiPath Studio, it automatically downloaded the package and component updates.
We ran with the Studio and it worked.
We executed with UiRobot and it worked.
This problem, when it appeared, I looked for information in the forum and found only PROXY validation, port validation, internet, permissions, but I think there is very little information when something like this happens. That’s why I upload the following information.
I hope it helps you if you have a case similar to mine.
Hi @Jean_Piere_Ochoa,
Thank you for sharing such good detailed feedback and information. I will push it for further investigation. Maybe there is something we could do about it.
I consulter this case with our team and it looks like you were not able to download the package from Robot. Most likely due proxy/internet configuration. The workaround you have used works as the package might have been found by Studio on another feed and since the nuget folder is shared between Studio and Robot it will work. But this is not a proper solution as this can break if the nuget cache is cleaned.
You should download the specific package and place it on Orchestrator if you are not able to ensure proper connectivity to myget.org/F/workflow/
Thank you very much for your response and support to this problem. Regarding the possible solution you mentioned, about the Internet /proxy configuration; we had no problem with those cases, since we had the network and support team that performed those validations and everything was correct.
Furthermore, I consider that this would not be the case, since the day before that problem, another robot was deployed in production and there was no problem.
It is worth mentioning that the package in the attached image was not used in the project (it was not downloaded from the package manager).
The last sentence actually tells me everything This was the reason actually. For such situation it’s worth to have dedicated network location in the environment where all “standalone” packages will be deployed and then add this path as a resource point in the configurations so both Studio and Robot will have access to it and will be able to resolve the dependency.
Hi @Pablito, I have the same issue, with an excel activity. I could download it manually from myget.org, but the assistant is not able to do it. We don’t have studio in that environment as it is a VM only used as unattended robot. Following your suggest I’ve uploaded manually the activity to the orchestrator (as a package) but still can’t install the process with the assistant (it is just an excel wb creation, to test the newly deployed production environment). Do you have any recommendation about how to do it?
Hi @dgallucci,
Normally it should work as soon as the robot/assistant is connected to the orchestrator. But if issue still persist I think you should contact with our Technical Support.
Another option that worked for me was to go to the path C: \ Users \ USER_HERE \ .nuget \ packages of the machine where I developed my robot and I copied those folders that had errors in Production. For example: if my error was UiPath.Activities, then I would go to the path described in the Development environment, look for the folder with the same name and paste them in the same path but in Production. That solved my mistake.
Another solution that worked for me was that before I was trying to upload the third party packages like (Bala Reva, Microsoft Word Interop packages) to my orchestrator libraries, but I could not find some packages in the default path( which can be checked from going to Uipath Studio-> Manage packages-> Settings-> The local default path to all your dependencies (Mine was C:\Users\USERNAME\AppData\Local\UiPath\app-21.4.4).
So then I went to C: \ Users \ USER_HERE \ .nuget \ packages and then uploaded all those packages that I have used in my libraries in the orchestrator and could not find in the default path and then cleared all my temp files(RUN-> %temp%) and then ran the process again from my UiPath Assistant and this resolved my issue and I did not get any error after that.
I am also having the same issue . The thing is that i can download old versions without a problem (they were not inside packages before) and i can download some new packages with lowable application version option. The strict option is giving the issue most. I dont thing any network problems make it happen. I have never come across that situation before 20.10 version.
This is not always a best solution to mannually copy or upload the packages in each robot/assistantant machines. I have the same issue, probably it is long but it will give completed understanding of the flow:
1- We have a 2 node orchestrator set for HA ,hence in this case we are using a shared drive to put all the nugget packages.
2- In Orchestrator.dll.config of both the orchestrator we have mentioned the path of nuget package as shared drive only.
3- So whenever we upload any code in our orchestrator the Nugget packages along with library are pushing it to the shared drive only because of the path defined in the Orchestrator.dll.config
4- In my case somehow while pushing the package on shared drive Uipath has created 2 Orchestrator folder in the shared drive. Probably each orchestrator node is creating a folder in the Shared drive to keep its nugget package.
5- So incase you are publishing the code from Orchestrator Node 1 it is pushing packages in its own folder, and in case you are installing the packages from Studio/UiPath assistant which is connected to Orchestrator Node 2, it is searching in the respective Shared drive folder which Orchestrator node 2 has created while publishing and it cannot find the same.
6- So to resolve this in my case I copied all the Packages from Orchestrator Node 1 folder to Orchestrator Node 2 folder, And it immediately started working.
May i ask what is the main cause here if you dont mind?
I publish my project to the orch and then start the project from orch or assistant. If I have last versions of packages, generally higher than default robot or studio version, then i ll get the error message in the robot most likely. If i repeat the starting process couple of times it gives the error again but job is starting succesfully in the third or forth. I have never come across that before. I think something new in 20.10 causes that problem but i couldnt find a proper solution. The only solution is that never use new versions of packages.
It may be that your current package version is not compatible with UIpath 2020.10 version and it is accepting only some old versions.
Sometimes newer packages consist of completely re-build schema for the activity and data used for the old one are incompatible with new schema. That’s why they become invalid and you need to place it again (in newer version) and provide needed data and attributes once again. I would say it works as designed.
Normally, we guarantee backward compatibility. That is, even if you use a newer Studio/Robot, you will still be able to Run the workflow as is.
What we can’t offer is Forward compatibility. Every once in a while, there are underlying changes that will make a specific activity package to not be compatible, but start with a specific version of Studio. In which case, you will get an Unresolved activity in the Workflow.
These situations are rather rare though and usually quite specific.
Alternative solution for you:
In Studio, import the errored package that fails to start in Assistant, update the UiPath.Activities to the latest update (also take a look if you have additional packages in your process that for their versions have some unsolved dependencies, in that case, repair them or download and install the missing dependencies), change the Project name, and publish the process back to Orchestrator. Try to re-run the process in Assistant.
Also, in order to get more details about an encountered error, you can take a look in Event Viewer and see the error trace details.
I was also facing the same issue, after a lot of struggle, I changed the package versions manually in the project.json file (copied from a running project file) and reopened the project. It started working.
This was the reason actually. For such situation it’s worth to have dedicated network location in the environment where all “standalone” packages will be deployed and then add this path as a resource point in the configurations so both Studio and Robot will have access to it and will be able to resolve the dependency.
Anil_G
ashokkarale
jinal.shah
Gautham_Pattabiraman
postwick
chandreshsinh.jadeja
vrdabberu
Ajay_Mishra
sven.wullum1
Vyshnavi_Nalumachu