[wasi] Library tests have no HOME/user profile (user secrets path) #135225

Summary

The WASI library-test guest has no HOME or usable user profile. Re-enabling Microsoft.Extensions.Configuration.Test.ConfigurationTests after fixing temporary file/directory creation exposes an independent failure in TouchingFileWillReloadForUserSecrets.

The test is in src/libraries/Microsoft.Extensions.Configuration/tests/FunctionalTests/ConfigurationTests.cs. It fails during test execution, before creating or watching the secrets file:

System.InvalidOperationException : Could not determine an appropriate location for storing user secrets. Set the DOTNET_USER_SECRETS_FALLBACK_DIR environment variable to a folder where user secrets should be stored.

This failure was hidden by the class-wide WASI quarantine against #134943, added in #134813. It is not a remaining mkstemps/mkdtemp failure.

Reproduction

At upstream main fa693c42fb6, apply the temporary-file fix from #134958 and remove the class-level ActiveIssue against #134943 from ConfigurationTests.

export DOTNET_WASM_TOOL_CACHE_DIR="$PWD/.dotnet/wasm-tools"
./build.sh -os wasi -arch wasm -rf CoreCLR -s clr+libs+host+packs -c Release
./dotnet.sh build src/libraries/Microsoft.Extensions.Configuration/tests/FunctionalTests/Microsoft.Extensions.Configuration.Functional.Tests.csproj /t:Test /p:TargetOS=wasi /p:TargetArchitecture=wasm /p:RuntimeFlavor=CoreCLR /p:Configuration=Release

On a macOS arm64 host with wasi-sdk 34 and wasmtime, the product build succeeds with zero warnings/errors. The suite reports 33 tests, 29 passed, 1 failed, 3 skipped. The sole failure is ConfigurationTests.TouchingFileWillReloadForUserSecrets; the other re-enabled configuration tests pass.

Likely cause and direction

Microsoft.Extensions.Configuration.UserSecrets.PathHelper searches APPDATA, HOME, special-folder paths, and DOTNET_USER_SECRETS_FALLBACK_DIR to locate user secrets. The WASI harness currently does not establish a guest home directory; the existing guest-variable forwarding does not set HOME.

The bundle root is preopened with --dir=., and the guest's /tmp resolves to the bundle's writable tmp/. A likely test-harness fix is a default guest variable:

<WasmEnvironmentVariable Include="HOME" Value="/tmp" />

Another candidate is DOTNET_USER_SECRETS_FALLBACK_DIR, but its behavior must be verified: the current path-selection chain uses ??, and special-folder queries can return an empty string rather than null.

Diagnostic confirmation

Running the same, unquarantined test bundle with only a guest HOME=/tmp override passes: 33 tests, 30 passed, 0 failed, 3 skipped.

PATH="$PWD/.dotnet:$PATH" WasmXHarnessMonoArgs='--env=HOME=/tmp' bash artifacts/bin/Microsoft.Extensions.Configuration.Functional.Tests/Release/net11.0/wasi-wasm/AppBundle/RunTests.sh

No repository or product-code change was required for that diagnostic. The normal test invocation still lacks the guest home default; this environment override is not part of #134958.

The fix should establish a writable guest profile without relying on host paths or changing the configuration API's contract. Re-enable the narrowly quarantined WASI TouchingFileWillReloadForUserSecrets test after the normal interpreter-lane invocation passes.