This affects all versions of Studio and Robot at least up to 2019.4.3
I believe it manifests regardless of library location (local, orchestrator, etc).
Attached is a zip with screenshots, an example project and library to reproduce.
LibraryBug.zip (116.8 KB)
Behaviour / manifestation
Consider a project with 2 workflow files:
- mainWorkflow.xaml, and
mainWf contains a loop which repeatedly calls processST.
processST does not handle errors. mainWf handles any exceptions raised by processST.
Our project has a dependency: myLibrary. processST uses myLibrary.abcActivity.
If / when abcActivity throws an exception:
- no handling in processST means e is raised to mainWf
- mainWf handles error
mainWf then continues its loop and again calls processSt.
Now arises the bug. After the first exception was thrown and correctly handled by mainWf, suddenly UiPath can no longer access processSoloTransaction.xaml. A new mscorlib exception arises:
Could not find file …\myLibrary\1.0.x\lib\net45\processSoloTransaction.xaml
Hang on. processST was never in myLibrary. Why is UiPath now looking there for this workfow?
The same mscorlib error is now thrown (and handled by mainWf) for every subsequent loop. We can no longer access processST during this execution.
This behaviour arises whenever there are any files inside the myLibrary project at library compile time which:
- have no extension (eg “dummyFile”. This includes the many no-extension files inside a project git directory), OR
- (in at least some cases) are non-xaml files in the library project directory (eg a desktop.ini file)
Removing/moving any such files, recompiling the library, and then updating the project dependency to the recompiled library, will stop the behaviour.
It seems these files are confusing either the compiler or Robot at runtime.
This issue will affect any git-initialised library project, and all projects which depend on it. It will probably also manifest in different forms not mentioned here.
- Create a new project with 2 workflows
- In workflow A, call workflow B twice consecutively. Wrap each call in its own try-catch, and log the error each time.
- Create a new library project with a single activity which throws any error.
- Add a new text file to the library project folder. Rename to ‘dummyFile’ (with no filetype extension)
- Publish the library.
- Add the library as a dependency to your project. Workflow B will call the lib thrower activity.
- Run workflow A.