[bug] Building for Windows Fails as System User (e.g., on AWS EC2)

[AnthonyNGarcia]

Describe the bug

Near the end of a Tauri Windows build, when it comes to bundling, Tauri seems to rely on some toolsets it installs in the user's AppData. However, in the context of AWS EC2 instances, build workloads are run under the systemuser. This means that installing these toolsets (e.g., WiX, NSIS) in this directory makes them unusable/executable, due to system/security restriction. The result/error is manifested without clear meaning, whether bundling .exe (using NSIS) or .msi (using WiX).

Only got to this conclusion because if I run the build on the same code in the same place, but as any other user, then Tauri installs the bundling tools in that other user's AppData, and then those bundling tools work perfectly fine for the Tauri build to succeed.

Datapoints:

• Reproduced this issue with the Tauri quickstart project
• The same code in the same directory builds successfully when doing the build as any non-system user. In this case, above toolchains are installed and run from that user's AppData. It only fails for the systemuser wherein above toolchains are installed to the un-usable system's AppData directory
• Regardless of whichever user I am (systemuser, non-system user), I am not able to run the candle.exe in that WiX toolset in the systemuser's AppData. In other words, it's not just Tauri that fails to launch it; no user can launch it either.

Reproduction

On a Windows Machine where you can access as systemuser (e.g., the only option for AWS EC2 workloads)

1. Follow Tauri QuickStart guide to setup a Tauri project on Windows.
2. Build the application, and get above reported error.
3. [Optional] As another user (non-system), build the same application exactly where it is, and see build succeed.

Expected behavior

The bundling toolchains that Tauri installs are expected to be installed at a location where they are usable. This would result in the expected behavior of Tauri build and bundling success, regardless of whether the caller is a systemuser or a non-system user.

At the least, it is expected to be able to configure where the toolchains are installed/referenced.

Full tauri info output

[✔] Environment
     - OS: Windows 10.0.20348 X64
     ✔ WebView2: 125.0.2535.67
     ✔ MSVC:
         - Visual Studio Build Tools 2019
         - Visual Studio Build Tools 2022
     ✔ rustc: 1.78.0 (9b00956e5 2024-04-29)
     ✔ cargo: 1.78.0 (54d8815d0 2024-03-26)
     ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
     ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
     - node: 18.20.3
     - npm: 10.7.0
 
 [-] Packages
     - tauri [RUST]: 1.6.1
     - tauri-build [RUST]: 1.5.1
     - wry [RUST]: 0.24.7
     - tao [RUST]: 0.16.7
     - @tauri-apps/api [NPM]: 1.5.3 (outdated, latest: 1.5.6)
     - @tauri-apps/cli [NPM]: 1.5.14
 
 [-] App
     - build-type: bundle
     - CSP: unset
     - distDir: ../dist
     - devPath: http://localhost:5173/
     - framework: React
     - bundler: Vite

Stack trace

Initial build logs (e.g., TAURI_TARGET_TRIPLE):

Running [tauri_cli::build] beforeBuildCommand `npm run build-app`
        Debug [tauri_cli::build] Setting environment for hook {"TAURI_ARCH": "x86_64", "TAURI_TARGET_TRIPLE": "x86_64-pc-windows-msvc", "TAURI_FAMILY": "windows", "TAURI_PLATFORM_VERSION": "10.0.20
 348", "TAURI_PLATFORM": "windows", "TAURI_PLATFORM_TYPE": "Windows_NT"}
      Running [tauri_cli] Command `cmd  /S /C npm run build-app`

Problem with NSIS for .exe bundling:

...{bunch of random, non-error debug logs}
Running [tauri_bundler::bundle::windows::nsis] makensis.exe to produce {omitted path}_x64-setup
 .exe
      Running [tauri_bundler::bundle::common] Command `C:\Windows\system32\config\systemprofile\AppData\Local\tauri\NSIS\makensis.exe  -V3 {truncated parent path}\src-tauri\target\release\nsis\x64\installer.nsi`
 Unable to start child process, error 0x2
        Error [tauri_cli_node] failed to bundle project: `The system cannot find the file specified. (os error 2)`

Note on above: the file does exist (just can't be run).

Problem with WiX for .msi bundling:

...{bunch of random, non-error debug logs}
      Running [tauri_bundler::bundle::windows::msi::wix] candle for "main.wxs"
      Running [tauri_bundler::bundle::common] Command `C:\Windows\system32\config\systemprofile\AppData\Local\tauri\WixTools\candle.exe  -arch x64 main.wxs -dSourceDir={omitted}.exe`
        Error [tauri_cli_node] failed to bundle project: error running candle.exe

Additional context

I know that there are GitHub actions for cross-compilation, but that isn't an option for us. Besides, this problem is not necessarily restricted to AWS EC2, as it would apply to any Windows host where systemuser is used for building.

[AnthonyNGarcia]

Working backwards from the .msi build failure:

• The WiX toolset path for the candle.exe is defined here, derived from appending to thewix_toolset_path.
• That value is passed in to the run_candle function by it's caller here.
• The caller of run_candle is build_wix_app_installer, who also gets it passed in.
• build_wix_app_installer in turn is provided this path value here as part of the bundle_project targeting MSI on Windows.
• bundle_project derives the path here by calling on another Rust crate dependency dirs_next:

let mut wix_path = dirs_next::cache_dir().unwrap();
wix_path.push("tauri/WixTools");

Also noting that this isn't just for the WiX toolset path, but also NSIS.

The dirs_next crate's documentation indicates that all such paths are always derived from the user's path: https://docs.rs/dirs-next/latest/dirs_next/index.html

...platform-specific, user-accessible locations

audio_dir | Returns the path to the user's audio directory.
cache_dir | Returns the path to the user's cache directory.
config_dir | Returns the path to the user's config directory.
data_dir | Returns the path to the user's data directory.

and so on and so on for every directory.

Given it is that crate's intent to provide paths to the user's directory, it is not a bug on their part that they are providing a user specific path. It's expected behavior for them to provide a path to the system if the system user is the one that kicks off this whole flow.

As such, it seems to land more squarely on the Tauri bundler to handle this edge case. Ideally, the Tauri bundler detects if it is running as the system user on Windows. It could then handle that by installing and calling these toolchains somewhere else than the dirs_next's provided user paths.

A simple solution may be install and reference it from the current project's workspace (the one being built). This would:

• Also be a known location that should be accessible, since it is the current project's workspace.
• Enable deterministic builds across different users, since project dependencies are in the project's workspace rather than being user-specific.
• Enable deterministic builds for the same user across multiple projects, in case they want to use a specific version for a specific project.
• Better support as-is offline builds wherein these tools can be configured in the project's workspace ahead-of-time (rather than configuring them on-the-fly).

Would that approach be acceptable to the maintainers?

(Also considered non-mutually exclusive approach of allowing user to customize path to WiX/NSIS, but above approach auto-fixes for the user without them needing to provide that custom path).