Scenario: Invoke Workflow breaks if previous invoke had an exception
Steps to reproduce:
Last stable behavior:
Last stable version: 2019.3.0
OS Version: Windows 10
Others if Relevant: (workflow, logs, .net version, service pack, etc):
In my flow I use a lot of library items. My automation works with portals. Current library version is 1.0.7036.28896. I have an invoke which breaks if one of the portals is offline. If so, It should skip it and continue to the next portal. The invoke path is defined as “Portals\XXXXXXXXXXXX.xaml”, its the path you get if .xaml is selected from root folder. Now, if it previous call breaks, I get a try catch exception on invoke
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\user.nuget\packages.…\1.0.7036.28896\lib\net45\Portals\XXXXXXXXXXXX.xaml
This path is different to the folder where I have the file. I do not save files or library to this folder. But it has the name of a library I use. Can anyone explain what is going on?
P.S. If I change relative path to absolute it works fine, but this is obviously not what I want.
I am having a similiar issue,
I am using the Enterprise Framework, and i have created some libraries that I published on orchestrator that i am callling on the Process.xaml, when something in my library encounters an error it throws a made-up Exception, then obviously it enter into the catch section for the invoke workflow for the Process, then my main workflow for some reason, when it tries to call SetTransaction.xaml it can’t, and sends me this error
SetTransactionStatus.xaml failed: Could not find a part of the path ‘C:\Users\90876\.nuget\packages\sap_va02selectlineitem\1.0.1\lib\net45\Framework\SetTransactionStatus.xaml’. at Source: mscorlib
and the process goes on with this fatal errors until it ends the process
Applications failed to close normally. Could not find a part of the path ‘C:\Users\90876\.nuget\packages\sap_va02selectlineitem\1.0.1\lib\net45\Framework\CloseAllApplications.xaml’. at Source: mscorlib
Invoke KillAllProcesses workflow: Could not find a part of the path ‘C:\Users\90876\.nuget\packages\sap_va02selectlineitem\1.0.1\lib\net45\Framework\KillAllProcesses.xaml’.
any idea why??, my best guess it maybe the library is not properly link or uiPath is not linking it properly, idk, any help is good
Usually if from the library is thrown an exception, this issue does not reproduce.
Interesting fact, the issue happens only when you have file of extensions other than .xaml in the library project folder. I had to add inside the library a folder with a .txt file and the issue was reproducing.
At runtime, when the library code executes, the current path is the one from C:\users<username>.nuget (About Automation Projects on the Robot). After the exception is thrown, and the code to execute is the current project code, still the current directory remained set to that value (in this particular case when you have other resources in the library).
In case you can not remove the other resources from the library, the workaround for fixing the issue would be to:
create a variable in which we save the current directory path, before invoking Process.xaml where you use the library ( SavedCurrentDirectoryVariable =Directory.GetCurrentDirectory)
on the catch Exception of invoke Process.xaml , use Invoke Method activity for System.IO.Directory.SetCurrentDirectory(SavedCurrentDirectoryVariable ) → this will reset the correct directory.
What works for me is rethrowing exception again in Catch inside workflow that I am invoking. It resets current directory to correct value
It also happens when I am using activity from library (directly on the process - NOT invoked on another workflow) - and rethrowing exception also works
I’m having this issue in 19.4.4, so it does not seem to have been fixed. It doesn’t appear to be due to my package, something went screwy with the xaml files of my project because it was working fine before I made a few more changes to another portion of the project.
To get around this issue, I am doing something similar to what @DanielaD suggested. I am unfortunately using the package throughout and it’s not contained to just my process file, so I changed all of my relative paths to static ones by using the get current directory method provided. That seems to be working but it’s pretty annoying.
@loginerror Unfortunately I can confirm that this bug is still present in Studio version 2019.10.4. We are experiencing this issue in multiple parts of our projects. As with @dmccammond, we are using different libraries in multiple workflows invoked throughout the projects and this issue continues to pop up.
Would really appreciate if this bug was put back into the bug fixes backlog. It’s causing quite a lot of headache for us