From 763af910428349e13f802f2581716327e86c10a3 Mon Sep 17 00:00:00 2001 From: Josh Knapp Date: Sun, 9 Aug 2026 22:19:12 -0700 Subject: [PATCH] Revert: LOCALAPPDATA override does not move Tauri's WiX cache Rust's `dirs` crate resolves LOCALAPPDATA on Windows through SHGetKnownFolderPath, which reads the process token rather than the environment, so the override changed nothing and 32-bit candle.exe still hit WOW64 redirection under the SYSTEM profile. Removing it rather than leaving a plausible-looking non-fix in the workflow. Co-Authored-By: Claude Opus 5 (1M context) --- .gitea/workflows/build-app.yml | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/.gitea/workflows/build-app.yml b/.gitea/workflows/build-app.yml index 67b4c11..eae95b3 100644 --- a/.gitea/workflows/build-app.yml +++ b/.gitea/workflows/build-app.yml @@ -339,22 +339,6 @@ jobs: build-windows: runs-on: windows-latest needs: [compute-version] - env: - # WiX 3.x candle.exe/light.exe are 32-bit. A runner running as SYSTEM has - # %LOCALAPPDATA% = C:\Windows\system32\config\systemprofile\AppData\Local, - # and Tauri caches the WiX toolset there. WOW64 redirection then sends a - # 32-bit process reading C:\Windows\System32 to C:\Windows\SysWOW64, where - # that directory does not exist - so candle.exe cannot see its own folder, - # the CLR fails to start, and Tauri reports only "failed to run - # candle.exe". The real error is 0x80131700, visible in the Application - # event log as ".NET Runtime ... could not be started". - # - # Verified on our runner: candle.exe -? exits 0 from C:\wixtest and - # 0x80131700 from the systemprofile path - same identity, same binary. - # - # Pointing LOCALAPPDATA outside System32 sidesteps redirection entirely, - # and is harmless on a runner that already runs as a normal user. - LOCALAPPDATA: C:\actions-runner-cache defaults: run: shell: cmd