Top-level folder path not respected when applying .NET configuration transforms using relative paths

[RobMcCarther]

Severity

No response

Version

2025.3.14311

Latest Version

I could reproduce the problem in the latest build

What happened?

When applying .NET configuration transforms in Octopus, transforms that include a top-level folder in the path fail to resolve as expected.

For example, given the following package structure:

MyApp/
├─Transforms/
│  ├─FileA.Transform.config
│  ├─FileB.Transform.config
│  └─FileC.Transform.config
├─FileA.config
├─FileB.config
└─FileC.config

These transforms fail:

MyApp/Transforms/FileA.Transform.config => MyApp/FileA.config
MyApp/Transforms/FileB.Transform.config => MyApp/FileB.config
MyApp/Transforms/FileC.Transform.config => MyApp/FileC.config

These transforms succeed:

Transforms/FileA.Transform.config => FileA.config
Transforms/FileB.Transform.config => FileB.config
Transforms/FileC.Transform.config => FileC.config

This behavior suggests that when the mapping includes the top-level folder (e.g., MyApp/), Octopus resolves the path as if it were nested (e.g., MyApp/MyApp/...), causing the transform folders not to be found.

Reproduction

Create a package with the following structure:

MyApp/
├─DeploymentFiles/
│ └─MyApp.Transform.config
├─runtimes/
│ └─MyApp.exe.config

Configure a .NET configuration transform in Octopus with the following definition: MyApp/DeploymentFiles/MyApp.Transform.config => MyApp/runtimes/MyApp.exe.config Deploy package and observe behavior

Error and Stacktrace

Note double "\MyApp\MyApp\"

Skipping as transform folder 'C:\Octopus\Applications\Development\MyApp\2.0.0.77_2\MyApp\MyApp\DeploymentFiles' does not exist

More Information

No response

Workaround

Omit the top-level folder reference in the transform definition