Compile error when using global usings with Error When Publishing Coded Workflows with Non-Primitive Types and Global Using Directives in UiPath LibrariesCoded Workflows

[Timothy_Morris]

Hi UiPath team,

I’ve encountered an issue with global using directives (introduced in C# 10) when working with Coded Workflows in UiPath. This language feature allows for centralizing using directives so they apply to all files, reducing redundancy at the top of each file. Here’s an example of a GlobalUsings.cs file:

Looks like this:

// GlobalUsings.cs
global using System;
global using System.Net;
global using System.Collections.Generic;

More on this feature here: C# Global Using Directives Documentation.

---

Problem

While global usings work correctly during development, publishing the library fails if my Execute method has a parameter that’s a non-primitive type (e.g., SecureString, List<string>). This happens when the compiler tries to convert Coded Workflows into activities, specifically during the “Compiling activities…” step, where it logs “COMPILER: Starting xaml documents compilation.”

Error Message

The Output panel displays the following error:

“Unable to create activity builder for {{WorkflowFilePath}}. Reason was ‘Value cannot be null. (Parameter ‘key’)’”

Investigation

After examining the generated code in LoginActivity.cs (or any generated activity file), I found that it explicitly references the qualified type names (e.g., System.Security.SecureString) instead of relying on global usings. For example:

[System.ComponentModel.Browsable(false)]
public class LogInActivity : System.Activities.Activity
{
    public InArgument<System.String> username { get; set; }

    public InArgument<System.Security.SecureString> password { get; set; }

    public LogInActivity()
    {
        this.Implementation = () =>
        {
            return new LogInActivityChild()
            {username = (this.username == null ? (InArgument<System.String>)Argument.CreateReference((Argument)new InArgument<System.String>(), "username") : (InArgument<System.String>)Argument.CreateReference((Argument)this.username, "username")), password = (this.password == null ? (InArgument<System.Security.SecureString>)Argument.CreateReference((Argument)new InArgument<System.Security.SecureString>(), "password") : (InArgument<System.Security.SecureString>)Argument.CreateReference((Argument)this.password, "password")), };
        };
    }
}

This prevents the use of global usings for non-primitive types in Execute method parameters, as they’re not applied in generated files.

---

Expected Behavior

It would be ideal if the compiler could recognize global usings in generated code files to support complex types in Execute parameters without this error.

---

Impact

This bug can block developers from leveraging global usings fully, especially in workflows with non-primitive types, potentially costing significant debugging time.

---

Request

Can the team investigate and resolve this so global using directives can be used seamlessly in all scenarios? I’m hopeful this report will also help others avoid the same issue.

---

Additional Information

UiPath Studio Version: 2024.10.5 and 2024.10.1

Thanks for your attention to this!

Thanks,

Tim

[Gabriela_Vaduva]

Hi, Tim!

Thanks for letting us know! I’ve investigated and it is indeed only at publish, at an internal step where trying to get the type. Unfortunately for now the only workaround is to not use global usings.

https://uipath.atlassian.net/browse/STUD-72800

[Timothy_Morris]

Hi Gabriela,

Thanks for investigating!

Global usings can still be used, but any types being used in a parameter need their namespace explicity added as a using at the top. I’ve compromised by doing this.

Tim

[Jon_Smith]

Do you mind testing if it works publishing via command line.

In my experience, when the code works in dev and you can also get it to run, but it then fails on publish its cause of the dumb workflow/project analyzer tooling, which throws up incorrect errors in the code.
This is proved by then publishing the code via command line and it then works, showing there was no compile errors as the analyzer claims.

It could be the same here.
I have requested multiple times to have the option to ignore the analyzer warnings and attempt a publish anyway as coded workflows isnt the only time or way its done this and even if you try to turn it off in all settings, some just cannot be turned off.