We're encountering test failures because dotnet workload restore attempts to write to paths that are not writable in containerized environments. This appears to be a common limitation in CI scenarios.

StdErr: Unhandled exception: Read-only file system : '/root/helix/work/correlation/d/metadata' , but found 1 (difference of 1).

@dotnet/domestic-cat @marcpopMSFT — is there a recommended workaround or best practice for handling this?

Can you clarify which part is going wrong? There's normally a metadata folder somewhere next to process path, so we're expecting to be able to access the spot right next to dotnet.exe or dotnet on linux. You can move the standard workload metadata folder that we write to if you set user local.

Can you clarify which part is going wrong? There's normally a metadata folder somewhere next to process path, so we're expecting to be able to access the spot right next to dotnet.exe or dotnet on linux. You can move the standard workload metadata folder that we write to if you set user local.

Thanks for the follow-up! Just to clarify, the issue is happening in the context of the two tests in this PR:

1. ProjectsThatDoNotSupportWorkloadsAreNotInspected
2. ProjectsThatDoNotSupportWorkloadsAndAreTransitivelyReferencedDoNotBreakTheBuild

These tests are failing in our containerized CI environment due to dotnet workload restore attempting to write to a read-only path:

Unhandled exception: Read-only file system : '/root/helix/work/correlation/d/metadata'
👉 Full pipeline failure log here

I tried setting the following environment variables in the test setup:

1. .WithEnvironmentVariable("DOTNET_CLI_HOME", cliHome)
2. .WithEnvironmentVariable("DOTNET_WORKLOAD_METADATA_DIR", metadataDir)
3. .WithEnvironmentVariable("DOTNET_SKIP_WORKLOAD_VERIFICATION", "true")

However, the error still occurs, which suggests that some part of the workload infrastructure is still trying to write to the default location. Is there another recommended way to fully redirect or disable workload-related writes in this scenario?

I believe that if you create a userlocal file, that is, a 0-byte file here (like C:\Program Files\dotnet\metadata\workloads\10.0.100\userlocal), it will only write to a directory under your DOTNET_CLI_HOME folder.

I'm not really sure what's being written. Are these from updating advertising manifests? If so, perhaps we could disable that?

I believe that if you create a userlocal file, that is, a 0-byte file here (like C:\Program Files\dotnet\metadata\workloads\10.0.100\userlocal), it will only write to a directory under your DOTNET_CLI_HOME folder.

I'm not really sure what's being written. Are these from updating advertising manifests? If so, perhaps we could disable that?

Thanks, that’s super helpful! I wasn’t aware of the userlocal file trick — I’ll try creating a 0-byte file at:

<dotnet-root>/metadata/workloads/<sdk-feature-band>/userlocal
and see if that redirects all writes to DOTNET_CLI_HOME as expected.