Robot fails with "Could not load file or assembly" error after upgrading from Robot 24.10 to 25.10 or later

News Knowledge Base
, , ,
1

Why does automation fail immediately with "Could not load file or assembly '...'. The system cannot find the file specified." on some robots but not others after a Robot version upgrade?

Issue Description:

An automation fails immediately when triggered, before any workflow logic executes, with an error indicating that a file or assembly could not be loaded. The name referenced in the error typically does not match the project's current name, often showing the original template name (for example, UiPath_REFramework) or an older project name that was later changed. This occurs on robots running Robot version 25.10 or later. In environments with a mix of Robot versions, the same package may run fine on machines still on 24.10 or earlier, while failing only on the ones upgraded to 25.10+.

Error message:

Could not load file or assembly '<name>, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

Typically accompanied by a stack trace referencing

UiPath.Executor.WorkflowLoader.GetWorkflowFromXamlPath and System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyName.

Root Cause:

UiPath projects store the project name in two internal files. When these fall out of sync, the Robot ends up looking for the wrong file.

  • project.json, the main project file. Every Studio version reads and writes this.
  • project.uiproj, a secondary file that only exists for projects created from a solution or template-based flow. Robot versions before 25.10 never read or write this file at all.

How the two drift apart:

  • When a project is renamed while working only in Studio 24.10 or earlier, project.json gets the new name, but project.uiproj is left behind on the original, often template-default, name.
  • Starting with Studio 25.10, project.uiproj's name takes priority when the project is opened. This can cause the two files to diverge further, or converge inconsistently, depending on which one was last saved.

Why this breaks the Robot:

  • At runtime, the Robot loads the compiled workflow assembly using the exact name found in the package's project.json.
  • When that name doesn't match the assembly actually inside the package, the Robot can't find the file and throws the error above.
  • This only shows up on Robot 25.10 and later, because earlier Robot versions never look at project.uiproj, so the mismatch never surfaces.

Example of the mismatch as it appears in the two files:

project.uiproj

{

"Name": "UiPath_REFramework",


"ProjectType": "Process",


"Description": "UiPath REFramework Template",


"MainFile": "Main.xaml"


}

project.json

{

"name": "MyAutomation_ProcessName",


…


"studioVersion": "24.10.5.0",


"projectVersion": "1.0.1"


}

Note how project.uiproj still shows the original template name while project.json correctly shows the renamed project. This mismatch is the trigger. Checking these two files on the affected project is the fastest way to confirm this issue is in play.

Resolution:

  1. Confirm access to Studio 25.10 or later (Studio Web also works).
  2. Open the affected project in that Studio version.
  3. Go to Project Settings and check the project Name field. An old or unexpected name may appear here, which is expected and part of the underlying behavior, not a sign of project corruption.
  4. Manually clear the field and retype the correct, current project name exactly.
  5. Save the project. Saving writes the corrected name consistently to the project's internal metadata.
  6. Publish a new package version.
  7. Deploy the new package to the affected robots and run a test job to confirm resolution.
  8. For machine pools with a mix of Robot versions, proactively republish and redeploy to all machines. Machines still on 24.10 will not currently show the issue with the old package, but any future upgrade to 25.10+ would trigger the issue on the existing package.