UiPath will not publish to Orchestrator if there is a workflow invoking another workflow

I’m running Enterprise version 2019.10.3.

Every workflow in my library works without error and will publish, EXCEPT if I have a workflow that invokes one or more workflows. I have tried deleting xaml files that will not publish and creating new ones. The files publish fine until I use an invoke.

Tried invoking all sorts of workflows. They run fine on their own, and they run fine being invoked. But they will not publish.

These are the logs I get whenever I invoke in a workflow and try to publish. It always says compile failed and gives these logs.
output.txt (236.5 KB)


Create a new process workflow. Have it comprised of 2 files only: File1 is a .xaml consistenting only of a sequence that invokes File2. File2 is an .xaml that only has a single write line that states “did this work”. Try and publish to see if that works

1 Like

That did work.

1 Like

@Logan.Albrecht it sounds like there is a validation error within one of your workflows then. Make sure ALL .xaml files in the folder do not have any validation errors, or else it will not compile.

1 Like

@Dave I’m not seeing any errors in any workflows, and they work individually, and they work when I invoke them and run them invoked. They just don’t compile then.

@Logan.Albrecht - please zip the file and upload the .zip

1 Like

@Dave RPI.Windows.Teams.zip (1.6 MB)
Appreciate you helping out!

@Logan.Albrecht It looks like your “main” file is missing? The project.json says the main is named “RetrievePCUsername.xaml” and it should be in the root folder of the project, but the .zip file does not have it in there?

@Dave Hmmm…it’s supposed to be a library. They don’t have main files, do they? And like I said, as long as I don’t invoke it publishes fine.

@Logan.Albrecht the project.json needs to be updated then, because it needs to point to the correct “main” .xaml - you can name it anything you’d like. “Main” is the actual file that runs when this library is referenced

Looking at https://docs.uipath.com/studio/docs/about-libraries in the section “Limitations when Publishing Libraries” it states that when using Invoke Workflow File activity, make sure the invoked file is located in the same folder as the library project. Are you trying to invoke things outside of the project folder, such as on a shared drive? Subfolders should be fine, it just can’t be outside the project folder.

Also, on the rare chance you are using Studio v2019.10.3 it says you can’t invoke from parent folders (meaning subfolders can invoke from it’s own folder or subfolders only). There is a workaround for this though, to use the legacy compiler which is just a flag within the development.json

@Dave I changed the json main to an existing top level workflow. That didn’t change anything. And I am invoking a workflow inside another workflow and they are all in the same folder. I pulled them out of any folders and tried and it still did not work. They invoke when I run them and do what I expect. But they will not publish while an invoke is happening. Tomorrow I’m going to try to make a new library and new xaml files and just copy the activities over and see if anything changes.

I created a whole new library and invoked a couple workflows and it published. Then I continued to work on it and suddenly it wouldn’t publish again unless I deleted the invokes, then it would. This is so frustrating.

make sure all invoked files are in root folder.

@bcorrea I have tried having them all in the same folder, and all in the root folder. Neither works. (And when I move the workflows for testing I rebuild the invoke).

i would check that again, cause that error is known to be a problem when we publish libraries with invoke files inside folders… another thing to do is not using relative paths, use full ones like c:\…\file.xaml

I have similar issue and change the compiler to use legacy compiler works. (https://docs.uipath.com/studio/docs/about-libraries#section-limitations-when-publishing-libraries)

Is this considered a bug? It doesn’t make sense to abandon folder structure and not use relative path for the new compiler when legacy compiler works perfectly.

yes, i think this is a bug… but i think using full file paths are a better workaround than messing with compiler…

The issue is fixed in 2019.10.4

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.