Libraries: Including files with certain names can wrongly cause errors during compiled execution

Feedback Studio
, ,
1

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
  • processSoloTransaction.xaml

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.

(Rough) cause

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.

Reproduce

  1. Create a new project with 2 workflows
  2. In workflow A, call workflow B twice consecutively. Wrap each call in its own try-catch, and log the error each time.
  3. Create a new library project with a single activity which throws any error.
  4. Add a new text file to the library project folder. Rename to ‘dummyFile’ (with no filetype extension)
  5. Publish the library.
  6. Add the library as a dependency to your project. Workflow B will call the lib thrower activity.
  7. Run workflow A.
2

There appears to at least one other scenario than can cause this same behaviour- unfortunately hard to identify at this point.

3

Hello dmarhshall,

Did you solved this issue ? I may want to have a config files inside a library project :/.

Thanks :).

4

Hi,
Thank you for your suggestion. I added it to our internal ideas tracker for our team to consider.

6

Hi Pablito, to clarify this isn’t a suggestion - it is a bug that can be caused simply by using the in-built git functionality within a library project, and then compiling. There are other scenarios that this issue affects, but git is one of them.

My workarounds to date:

  • For git: initialise the project in a parent folder, not in the project folder
  • For windows sytem files eg desktop.ini : you have to manually find and remove these from the project folder every time you compile
  • For other files eg configs: You just can’t include them in the project directory for a library.
1 Like