CLI pack command missing type information for custom C# types in coded workflows, causing Orchestrator error 400 in CLI publish command

[denyscho]

Summary

When using uipath studio package pack to pack a project containing coded workflows (C# files) with custom types as parameters, the generated project.json is missing the type field for custom type parameters. This causes Orchestrator to reject the package with error code 400 (invalid arguments).

Environment

• CLI Version: uipathcli v2.0.47 (windows, amd64)
• UiPath Studio Version: 2023.10.4 Enterprise
• Operating System: Windows 11 Pro 26200.6899
• Project Type: Process with coded workflows (C#)

Steps to Reproduce

1. Create a UiPath project with a coded workflow (C# file)
2. Add a method with a custom type parameter:

   // Controller/Report/GetMainTableRow.cs
   public DataRow GetMainTableRow(
       DataTable MainTable, 
       OrchestratorQueue OrchestratorQueue)  // Custom type
   {
       // ... implementation
   }
   

3. Pack the project using CLI:

   uipath.exe studio package pack --source "project.json" --destination ".artifacts"
   

4. Inspect the generated project.json in the .nupkg file
5. Attempt to publish to Orchestrator using CLI:

   uipath.exe studio package publish --source "package.nupkg"
   

Expected Behavior

The project.json in the packed .nupkg should contain complete type information for all parameters, including custom types:

{
  "entryPoints": [
    {
      "filePath": "Controller\\Report\\GetMainTableRow.cs",
      "uniqueId": "22501d62-a9a6-4747-b131-8c340cb0298f",
      "input": [
        {
          "name": "MainTable",
          "type": "System.Data.DataTable, System.Data.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a",
          "required": true,
          "hasDefault": false
        },
        {
          "name": "OrchestratorQueue",
          "type": "ExceptionReporter.Model.OrchestratorQueue, ExceptionReporter.Core, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null",
          "required": true,
          "hasDefault": false
        }
      ],
      "output": []
    }
  ]
}

Actual Behavior

The CLI-packed project.json is missing the type field for the custom type parameter:

{
  "entryPoints": [
    {
      "filePath": "Controller\\Report\\GetMainTableRow.cs",
      "uniqueId": "22501d62-a9a6-4747-b131-8c340cb0298f",
      "input": [
        {
          "name": "MainTable",
          "type": "System.Data.DataTable, System.Data.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a",
          "required": true,
          "hasDefault": false
        },
        {
          "name": "OrchestratorQueue",
          "required": true,
          "hasDefault": false
          // ❌ MISSING "type" field!
        }
      ],
      "output": []
    }
  ]
}

Error When Publishing to Orchestrator

Orchestrator returned status code '400' and body '{"message":"Entry point with unique id:22501d62-a9a6-4747-b131-8c340cb0298f has invalid arguments.","errorCode":2006,"traceId":"00-0f591fb413536b76cab00a87fce216ef-2a7d32ea3b064d8a-00"}'
ERROR: Publish failed

Comparison with UiPath Studio

When packing the exact same project in UiPath Studio

• ✅ The type field is included for custom types
• ✅ The package publishes successfully to Orchestrator
• ✅ No validation errors

This confirms the issue is specific to the CLI pack command.

Additional Notes

• Standard .NET types (like System.Data.DataTable) are properly included by CLI
• Only custom types from the project are missing type information
• The issue occurs even when the project compiles and works correctly in Studio
• After packing with CLI, the project opened in Studio shows warning: "coded types may not be available in workflows due to error"

Impact

This prevents using the CLI for CI/CD pipelines with coded workflows that utilize custom types, a typical pattern in modern UiPath development.

No --compile, --build, or similar flag available to ensure C# types are resolved adequately before packing.

Request

Could the CLI pack command be enhanced to:

1. Properly detect and include type information for custom C# types in coded workflows
2. Or provide a --compile or --build flag to ensure types are resolved before packing
3. Or provide better error messaging when custom types cannot be resolved

Related

This may be related to how the CLI resolves types from compiled assemblies versus how Studio does it during the pack process.