fix(windows): Fix Windows System User build failures by using the current directory for bundling tools (fix: 9895)

[AnthonyNGarcia]

Closes #9895 with details on the issue there.

As a summary: Tauri uses Wix/NSIS toolsets for bundling .msi and .exe files respectively. Currently, it installs/retrieves these toolchains from the user app directory. However, this approach fails if the current user is a System user, since their app directory (the system directory) is restricted, which results in the bundling failing due to unusable Wix/NSIS executables.

This PR solves the problem by instead installing/retrieving the Wix/NSIS toolset from the current project directory, in target/tools. For example, Wix would be at target/tools/Wix. This would:

• Be a known location that should be accessible, since it is the current project's workspace.
• Enable deterministic builds across different Windows Users, since the tools are in the project's workspace rather than being user-specific
• Enable controlled builds for the same Windows User across different Tauri projects, in case support comes later to use a specific version of these tools 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).

Tested this code change locally:

• cargo test
• cargo clippy
• Using it on my Windows machine with Tauri Quickstart guide example, to generate .msi and .exe (tests Wix and NSIS flows, respectively). They both built successfully. Also confirmed both of them work for app installation

[FabianLars]

Agreed with Amr, just wanted to mention that this would need a proper target dir detection (similar to how the bundle/ folder gets placed) because <cwd>/target/ is simply incorrect tbh.

[AnthonyNGarcia]

Great callout, thank you folks. I like the suggestion to keep the existing behavior as default given it is more optimal for most use cases. I've put the feature behind a feature flag in the Tauri config json with schema validation. I believe this approach accomplishes the best of both worlds: gating the feature, but also minimizing risk of build errors associated with CLI usage and flags, by leveraging the feature via schema validation. After all, someone who needs this feature needs this all the time, so setting it once in the config and being safe would be preferred (at least speaking from the voice of one such person who wants to consume this fix).

Tested that the new json config property is fully optional. If not provided at all, defaults to false (aka existing behavior). Also tested if false is explicitly provided (again, existing behavior). Finally, when true is provided (new behavior, working).

As for the callout on getting to target directory more correctly, good callout. I updated it to traverse up one from the available project_out_directory. Do let me know if you are aware of a better way to get to the target directory. I also considered just putting these tools directly in project_out_directory but it name conflicts with existing folders there wix and nsis which are holding intermediate artifacts.

[AnthonyNGarcia]

As per offline discussion in Discord, moved the feature from bundle.windows up to bundle directly as it could apply to other platforms (though this PR just implements it for Windows). Updated docs accordingly and renamed tool folder from tools -> .tauri-tools

[FabianLars]

I also considered just putting these tools directly in project_out_directory but it name conflicts with existing folders there wix and nsis which are holding intermediate artifacts.

Hmm, maybe something like this (copy pasted from somewhere else in the cli)

  let mut path = get_cargo_metadata()
    .with_context(|| "failed to get cargo metadata")?
    .target_directory;

Using the parent dir of project_out_directory is probably a bit awkward because it will be different if the user uses the --target flag, duplicating the tools at which point you may as well use project_out_directory directly (with the extra .tauri-tools folder) just to be safe.

[MystiPanda]

I just tested this PR and didn't make any changes to tauri.conf.json, I got permissions error on GitHub Actions: https://github.com/clash-verge-rev/clash-verge-rev/actions/runs/9360177885/job/25765128485

[MystiPanda]

Well, unrelated, I found out that #9902 caused the problem.