Compilation failed when invoke workflow from subfolder

Hi,

I have a Library project where my workflows resides in subfolders

Example:
/Core/Activity1
/Core/Activity2

Since today I get compilation error when publishing the library.
''Unexpected error has occurred during the library compilation process:
System.AggregateException: One or more errors occurred. —> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.

The problem occures if /Core/Activity1 do a ‘Invoke Workflow File’ of /Core/Activity2

I guess this is a bug in some resent update. Anyone have an idea how can I get around this problem without changing my folder structure?

I’m using
Studio 2019.10.3 - 1/20/2020
Community License
EXE Installer
Microsoft Windows 10 Enterprise 64-bit
.NET Framework Version 4.7.2 or later

Hi
welcome back to uipath community

but the error shows like the key mentioned is not the one in the dictionary variable
is it so
kindly check that once if any collection variable is accessed along that workflow with a key value pair
Cheers @Brasse2873

Just last week I was experimenting with compilation into library and I faced the same problem in 19.10.1 version.

Resolved by moving all WF into root folder.

Cheers

I have no dictionary in my project nor any arguments in the workflows. I made a simple “empty” project with 2 workflow.

Are you using full file path or project relative ones?

Relative “Core/Activity2.xaml”

then for a test, try full…

That workts. This will work for now. I hope UiPath will fix this bug until I need to move the project.
Thanks!

2 Likes

This error is not linked to your workflow but it is caused by the compilation process. It seems sub-folders are not supported in library - although this limitation is not documented - although this is not unusual in UiPath :slight_smile: Hard to say if this is bug or feature :slight_smile:

If you check the output panel you will see there a warning in preprocess phase.

I did a quick test now:
I put WF1 and WF2 in a subfolder, WF1 invokes WF2 using relative path - compilation failed.
After removing the invoke of WF2 from WF1 the compilation finished.

@loginerror: Could you pls advise?

Cheers

But when you run the library, it should not look for the workflows using the full path, so i hope…

I have been using libraries for a year and it has been working until this week.

I guess full path will not work in runtime. I have to test that.

Pls post here result of your testing.
Thx

My test showed that the library worked fine in runtime. I moved the code so there were no code where ‘Invoke Workflow file’ pointed at. Test was done from orchestrator and from studio.

1 Like

Hi @Brasse2873

Could you see if this documentation bit fixes your issue?

The workaround resolves the issue but -

What is the difference/advantages between the legacy library compiler and the modern library compiler other than the disadvantage of not being able to organize the XAMLs in it’s respective folders?

By using the legacy compiler, what impact does it have on the existing Jenkins build etc for CI/CD? Any changes required there as well? Please advise.

@Teja_G This issue is fixed in Studio 2019.10.4.
By using the new library compiler a library compile time should be faster, also the load time of compiled activities should be faster.
It shouldn’t have any impact on existing Jenkins builds for CI/CD unless you use “UiPath.ActivityCompiler.CommandLine.exe” in your builds. By default the command line application will compile a library using the legacy compiler unless you specify the flag ‘-useCSharpCompiler true’ to use the new compiler.

1 Like

TL:DR; The compiler compiles commented out code (disable activity), as a reason why publishing a library using 2019.10 throws errors the The given key was not present in the dictionary error message. hth

One note, if someone has somehow gotten to the bottom of this thread and is reading this without having a resolution. Not sure if this should be recorded as an issue or not, but in my case, my compilation issues were due to one file, having an invoke workflow activity to an external file system file. I know this isn’t legit when building a library, but what was interesting is that the invoke workflow activity was commented out. The only highlight here, whether it’s right or wrong to compile it, is that it’s different than previous versions. I don’t see anywhere in any of the comments of this specific scenario. The commented out code was there before i upgraded to 2019.10. Figured i’d share.

That is interesting, it is good to comment so developers can look into this also. :slight_smile: