Repository navigation
feat(v3/nsis): add user install scope for Windows NSIS installer - #5305
Conversation
Port of #5094 to v3. Adds INSTALL_SCOPE variable (default: machine) to the Windows Taskfile. When set to "user", makensis receives -DWAILS_INSTALL_SCOPE=user and -DREQUEST_EXECUTION_LEVEL=user, causing the installer to: - Install to $LOCALAPPDATA\Programs instead of $PROGRAMFILES64 - Write uninstall entries to HKCU instead of HKLM - Request user-level execution (no UAC prompt) Defaults WAILS_INSTALL_SCOPE to "machine" in wails_tools.nsh so macros use a single !if branch without an outer !ifdef guard (CodeRabbit nitpick). Documents WAILS_INSTALL_SCOPE in project.nsi comment block alongside REQUEST_EXECUTION_LEVEL (CodeRabbit suggestion). Updates the wails_tools.nsh template and regenerates all example files.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughAdds a configurable NSIS install scope via ChangesInstall scope + build integration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR adds configurable install scope support to the v3 Windows NSIS packaging flow so Wails apps can be built either as the existing machine-wide installer or as a per-user installer. It updates the shared NSIS build assets and regenerates the example installer scripts to reflect the new scope-aware behavior.
Changes:
- Adds an
INSTALL_SCOPETaskfile variable and forwards it into NSIS packaging/signing tasks. - Makes NSIS installer behavior scope-aware for default install path and uninstall registry hive selection.
- Regenerates example
project.nsi/wails_tools.nshfiles to match the updated templates.
Reviewed changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
v3/internal/commands/updatable_build_assets/windows/nsis/wails_tools.nsh.tmpl |
Adds default install-scope define and switches uninstall registry write/delete between HKLM and HKCU. |
v3/internal/commands/build_assets/windows/nsis/project.nsi.tmpl |
Makes default InstallDir conditional on the chosen scope and documents the new define. |
v3/internal/commands/build_assets/windows/Taskfile.yml |
Introduces INSTALL_SCOPE plumbing into NSIS package/sign tasks and sets user-level NSIS defines when requested. |
v3/examples/notifications/build/windows/nsis/wails_tools.nsh |
Regenerated example installer helper with scope-aware uninstall registry handling. |
v3/examples/notifications/build/windows/nsis/project.nsi |
Regenerated example installer script with scope-aware install directory. |
v3/examples/ios/build/windows/nsis/wails_tools.nsh |
Regenerated example installer helper with scope-aware uninstall registry handling. |
v3/examples/ios/build/windows/nsis/project.nsi |
Regenerated example installer script with scope-aware install directory. |
v3/examples/file-association/build/nsis/wails_tools.nsh |
Regenerated example installer helper with scope-aware uninstall registry handling. |
v3/examples/file-association/build/nsis/project.nsi |
Regenerated example installer script with scope-aware install directory. |
v3/examples/dock/build/windows/nsis/wails_tools.nsh |
Regenerated example installer helper with scope-aware uninstall registry handling. |
v3/examples/dock/build/windows/nsis/project.nsi |
Regenerated example installer script with scope-aware install directory. |
v3/examples/custom-protocol-example/build/windows/nsis/wails_tools.nsh |
Regenerated example installer helper with scope-aware uninstall registry handling. |
v3/examples/custom-protocol-example/build/windows/nsis/project.nsi |
Regenerated example installer script with scope-aware install directory. |
v3/examples/badge/build/windows/nsis/wails_tools.nsh |
Regenerated example installer helper with scope-aware uninstall registry handling. |
v3/examples/badge/build/windows/nsis/project.nsi |
Regenerated example installer script with scope-aware install directory. |
v3/examples/badge-custom/build/windows/nsis/wails_tools.nsh |
Regenerated example installer helper with scope-aware uninstall registry handling. |
v3/examples/badge-custom/build/windows/nsis/project.nsi |
Regenerated example installer script with scope-aware install directory. |
v3/examples/android/build/windows/nsis/wails_tools.nsh |
Regenerated example installer helper with scope-aware uninstall registry handling. |
v3/examples/android/build/windows/nsis/project.nsi |
Regenerated example installer script with scope-aware install directory. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| !ifndef WAILS_INSTALL_SCOPE | ||
| !define WAILS_INSTALL_SCOPE "machine" | ||
| !endif | ||
|
|
||
| !ifndef REQUEST_EXECUTION_LEVEL | ||
| !define REQUEST_EXECUTION_LEVEL "admin" |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
v3/examples/file-association/build/nsis/wails_tools.nsh (1)
182-182:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winPre-existing bug: missing
\before GUID in HKCU WebView2 registry pathLine 182 (unchanged in this PR) reads a wrong registry key —
Clients{F3017...}instead ofClients\{F3017...}:- ReadRegStr $0 HKCU "Software\Microsoft\EdgeUpdate\Clients{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}" "pv" + ReadRegStr $0 HKCU "Software\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}" "pv"This path will never match the actual registry value, so the WebView2 user-level detection silently fails — the bootstrapper will re-download and re-run WebView2 on every user-scope install even when it's already present. All other
wails_tools.nshfiles in this PR have the correct path (e.g., identical line inv3/examples/ios/build/windows/nsis/wails_tools.nshorv3/examples/notifications/build/windows/nsis/wails_tools.nsh).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@v3/examples/file-association/build/nsis/wails_tools.nsh` at line 182, The ReadRegStr call using the HKCU path is missing a backslash before the GUID in the registry key string (currently "Clients{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}") so it never matches WebView2's actual key; update the ReadRegStr invocation to use "Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}" (i.e., insert the missing backslash before the GUID) so the WebView2 user-level detection succeeds.v3/examples/ios/build/windows/nsis/wails_tools.nsh (1)
118-164:⚠️ Potential issue | 🟠 MajorReplace REQUEST_EXECUTION_LEVEL checks with WAILS_INSTALL_SCOPE for consistent user-scope handling
The
wails.setShellContext(line 159) andwails.webview2runtime(line 180) macros checkREQUEST_EXECUTION_LEVELinstead ofWAILS_INSTALL_SCOPE. While the main build system correctly couples both flags (-DWAILS_INSTALL_SCOPE=user -DREQUEST_EXECUTION_LEVEL=usertogether whenINSTALL_SCOPE=user), the NSIS macros remain architecturally fragile—they depend on correct external pairing rather than checking the authoritative scope indicator directly. Switching these macros to checkWAILS_INSTALL_SCOPE(which now defaults to "machine" per the PR) makes the code self-consistent and eliminates the risk of misconfiguration.Proposed changes
!macro wails.setShellContext - ${If} ${REQUEST_EXECUTION_LEVEL} == "admin" + !if "${WAILS_INSTALL_SCOPE}" == "user" + SetShellVarContext current + !else SetShellVarContext all - ${else} - SetShellVarContext current - ${EndIf} + !endif !macroendAnd in
wails.webview2runtime(line 180):- ${If} ${REQUEST_EXECUTION_LEVEL} == "user" + !if "${WAILS_INSTALL_SCOPE}" == "user" # If the installer is run in user level, check the user specific key exists and is not empty then webview2 is already installed ReadRegStr $0 HKCU "Software\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}" "pv" ${If} $0 != "" Goto ok ${EndIf} - ${EndIf} + !endif🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@v3/examples/ios/build/windows/nsis/wails_tools.nsh` around lines 118 - 164, The macros wails.setShellContext and wails.webview2runtime use REQUEST_EXECUTION_LEVEL to decide behavior; change them to test WAILS_INSTALL_SCOPE instead so the code relies on the authoritative install-scope flag. Concretely, replace any conditional that checks ${REQUEST_EXECUTION_LEVEL} (e.g., ${If} ${REQUEST_EXECUTION_LEVEL} == "admin" ... ${else} ...) with a check on WAILS_INSTALL_SCOPE (e.g., compare "${WAILS_INSTALL_SCOPE}" to "machine" or "user" and set SetShellVarContext and other branch-specific actions accordingly) so machine-scope uses the "all" shell context and user-scope uses the "current" context; apply the same swap in the wails.webview2runtime macro.
🧹 Nitpick comments (4)
v3/internal/commands/build_assets/windows/nsis/project.nsi.tmpl (1)
76-84: 💤 Low value
!elsefallback is dead code — the!ifdefguard is redundant
wails_tools.nshis!included at line 36, before this block. Becausewails_tools.nshunconditionally definesWAILS_INSTALL_SCOPEvia its!ifndefguard (defaulting to"machine"),WAILS_INSTALL_SCOPEis always defined by the time the preprocessor reaches line 76. The!elsebranch (lines 82–84) can never be reached.The same pattern (and the same dead branch) is replicated across all generated
project.nsiexamples in this PR.♻️ Simplified form
-!ifdef WAILS_INSTALL_SCOPE - !if "${WAILS_INSTALL_SCOPE}" == "user" - InstallDir "$LOCALAPPDATA\Programs\${INFO_PRODUCTNAME}" - !else - InstallDir "$PROGRAMFILES64\${INFO_COMPANYNAME}\${INFO_PRODUCTNAME}" - !endif -!else - InstallDir "$PROGRAMFILES64\${INFO_COMPANYNAME}\${INFO_PRODUCTNAME}" -!endif +!if "${WAILS_INSTALL_SCOPE}" == "user" + InstallDir "$LOCALAPPDATA\Programs\${INFO_PRODUCTNAME}" +!else + InstallDir "$PROGRAMFILES64\${INFO_COMPANYNAME}\${INFO_PRODUCTNAME}" +!endif🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@v3/internal/commands/build_assets/windows/nsis/project.nsi.tmpl` around lines 76 - 84, The outer preprocessor guard using "!ifdef WAILS_INSTALL_SCOPE" is redundant because wails_tools.nsh already defines WAILS_INSTALL_SCOPE, so remove the "!ifdef WAILS_INSTALL_SCOPE" / corresponding "!else" / "!endif" wrapper and keep a single value-based conditional (e.g. "!if "${WAILS_INSTALL_SCOPE}" == "user" ... !else ... !endif") that sets InstallDir (the InstallDir lines and the value-check for WAILS_INSTALL_SCOPE should remain); apply the same removal of the dead "!else" fallback in all project.nsi.tmpl instances that include wails_tools.nsh so only the meaningful value-based branch (and its else) remain.v3/internal/commands/updatable_build_assets/windows/nsis/wails_tools.nsh.tmpl (1)
30-38: Template improvement: CoupleREQUEST_EXECUTION_LEVELtoWAILS_INSTALL_SCOPEfor clarityThe
wails_tools.nsh.tmpltemplate currently has decoupled defaults whereREQUEST_EXECUTION_LEVELdefaults to"admin"independently ofWAILS_INSTALL_SCOPE. While the Taskfile build system (lines 127–129 ofv3/internal/commands/build_assets/windows/Taskfile.yml) passes bothINSTALL_SCOPE=userandREQUEST_EXECUTION_LEVEL=usertogether when invoked withINSTALL_SCOPE=user, the template itself doesn't document or enforce this relationship.For defensive coding and clarity, derive the
REQUEST_EXECUTION_LEVELdefault fromWAILS_INSTALL_SCOPEso the template is self-consistent and works correctly even if variables are passed independently:Proposed improvement
!ifndef WAILS_INSTALL_SCOPE !define WAILS_INSTALL_SCOPE "machine" !endif +!ifndef REQUEST_EXECUTION_LEVEL + !if "${WAILS_INSTALL_SCOPE}" == "user" + !define REQUEST_EXECUTION_LEVEL "user" + !else + !define REQUEST_EXECUTION_LEVEL "admin" + !endif +!endif -!ifndef REQUEST_EXECUTION_LEVEL - !define REQUEST_EXECUTION_LEVEL "admin" -!endif🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@v3/internal/commands/updatable_build_assets/windows/nsis/wails_tools.nsh.tmpl` around lines 30 - 38, The template sets REQUEST_EXECUTION_LEVEL to a hardcoded "admin" default independent of WAILS_INSTALL_SCOPE; change it so REQUEST_EXECUTION_LEVEL is derived from WAILS_INSTALL_SCOPE (e.g., if WAILS_INSTALL_SCOPE == "user" then default REQUEST_EXECUTION_LEVEL to "user", otherwise default to "admin") instead of always defining "admin", update the !ifndef/!define logic around REQUEST_EXECUTION_LEVEL and keep the existing RequestExecutionLevel "${REQUEST_EXECUTION_LEVEL}" line so the generated NSIS script reflects the install scope when no explicit REQUEST_EXECUTION_LEVEL is passed.v3/examples/dock/build/windows/nsis/project.nsi (1)
76-84: 💤 Low value
!elsebranch is unreachable dead code
!include "wails_tools.nsh"at line 36 is processed first and always definesWAILS_INSTALL_SCOPEto"machine"via its!ifndefguard. By the time the!ifdef WAILS_INSTALL_SCOPEcheck at line 76 runs, the symbol is always defined regardless of whether the caller passed-Dor not — making the!elsebranch (lines 82–84) dead code. A simpler form that removes the outer!ifdefguard and retains only the inner!ifis sufficient:♻️ Proposed simplification
-!ifdef WAILS_INSTALL_SCOPE - !if "${WAILS_INSTALL_SCOPE}" == "user" - InstallDir "$LOCALAPPDATA\Programs\${INFO_PRODUCTNAME}" - !else - InstallDir "$PROGRAMFILES64\${INFO_COMPANYNAME}\${INFO_PRODUCTNAME}" - !endif -!else +!if "${WAILS_INSTALL_SCOPE}" == "user" + InstallDir "$LOCALAPPDATA\Programs\${INFO_PRODUCTNAME}" +!else InstallDir "$PROGRAMFILES64\${INFO_COMPANYNAME}\${INFO_PRODUCTNAME}" -!endif +!endifThe same simplification applies to
v3/examples/custom-protocol-example/build/windows/nsis/project.nsi,v3/examples/ios/build/windows/nsis/project.nsi, and the source templatev3/internal/commands/build_assets/windows/nsis/project.nsi.tmpl.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@v3/examples/dock/build/windows/nsis/project.nsi` around lines 76 - 84, The outer conditional using !ifdef WAILS_INSTALL_SCOPE is redundant because wails_tools.nsh always defines WAILS_INSTALL_SCOPE; remove the outer !ifdef/!else/!endif and replace with a single !if "${WAILS_INSTALL_SCOPE}" == "user" ... !else ... !endif block that sets InstallDir to "$LOCALAPPDATA\Programs\${INFO_PRODUCTNAME}" for user and "$PROGRAMFILES64\${INFO_COMPANYNAME}\${INFO_PRODUCTNAME}" otherwise; apply the same simplification to the other mentioned NSIS files and the template so only the inner !if branch (checking "${WAILS_INSTALL_SCOPE}" == "user") and its !else remain.v3/examples/android/build/windows/nsis/wails_tools.nsh (1)
30-36: ⚡ Quick win
REQUEST_EXECUTION_LEVELshould be auto-derived fromWAILS_INSTALL_SCOPEwhen not explicitly set.The two defines are independent defaults, but a correct user-scope install requires both to be set to
"user". If someone invokesmakensismanually with only-DWAILS_INSTALL_SCOPE=user(as the developer workflow inproject.nsi's header comments suggests), the installer will write toHKCUand install to$LOCALAPPDATA, yet still request admin execution level (UAC prompt) and callSetShellVarContext all— an inconsistent state.The fix belongs in
wails_tools.nsh.tmpl(then re-generate all examples): replace theREQUEST_EXECUTION_LEVEL!ifndefblock with a scope-aware default:♻️ Proposed fix in
wails_tools.nsh.tmpl/ generatedwails_tools.nsh!ifndef REQUEST_EXECUTION_LEVEL - !define REQUEST_EXECUTION_LEVEL "admin" + !if "${WAILS_INSTALL_SCOPE}" == "user" + !define REQUEST_EXECUTION_LEVEL "user" + !else + !define REQUEST_EXECUTION_LEVEL "admin" + !endif !endifThis keeps the
!ifndefguard so an explicit-DREQUEST_EXECUTION_LEVEL=...command-line flag still overrides the derived default.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@v3/examples/android/build/windows/nsis/wails_tools.nsh` around lines 30 - 36, The REQUEST_EXECUTION_LEVEL default must be derived from WAILS_INSTALL_SCOPE when not explicitly provided: replace the current !ifndef REQUEST_EXECUTION_LEVEL block with logic that, if WAILS_INSTALL_SCOPE is "user", defines REQUEST_EXECUTION_LEVEL to "user" and otherwise defines it to "admin", while preserving the !ifndef guard so a manual -DREQUEST_EXECUTION_LEVEL=... still overrides; implement this change in the wails_tools.nsh.tmpl (and regenerate the generated wails_tools.nsh/examples) and reference the WAILS_INSTALL_SCOPE and REQUEST_EXECUTION_LEVEL symbols when locating the block to change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@v3/examples/file-association/build/nsis/wails_tools.nsh`:
- Line 182: The ReadRegStr call using the HKCU path is missing a backslash
before the GUID in the registry key string (currently
"Clients{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}") so it never matches WebView2's
actual key; update the ReadRegStr invocation to use
"Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}" (i.e., insert the missing
backslash before the GUID) so the WebView2 user-level detection succeeds.
In `@v3/examples/ios/build/windows/nsis/wails_tools.nsh`:
- Around line 118-164: The macros wails.setShellContext and
wails.webview2runtime use REQUEST_EXECUTION_LEVEL to decide behavior; change
them to test WAILS_INSTALL_SCOPE instead so the code relies on the authoritative
install-scope flag. Concretely, replace any conditional that checks
${REQUEST_EXECUTION_LEVEL} (e.g., ${If} ${REQUEST_EXECUTION_LEVEL} == "admin"
... ${else} ...) with a check on WAILS_INSTALL_SCOPE (e.g., compare
"${WAILS_INSTALL_SCOPE}" to "machine" or "user" and set SetShellVarContext and
other branch-specific actions accordingly) so machine-scope uses the "all" shell
context and user-scope uses the "current" context; apply the same swap in the
wails.webview2runtime macro.
---
Nitpick comments:
In `@v3/examples/android/build/windows/nsis/wails_tools.nsh`:
- Around line 30-36: The REQUEST_EXECUTION_LEVEL default must be derived from
WAILS_INSTALL_SCOPE when not explicitly provided: replace the current !ifndef
REQUEST_EXECUTION_LEVEL block with logic that, if WAILS_INSTALL_SCOPE is "user",
defines REQUEST_EXECUTION_LEVEL to "user" and otherwise defines it to "admin",
while preserving the !ifndef guard so a manual -DREQUEST_EXECUTION_LEVEL=...
still overrides; implement this change in the wails_tools.nsh.tmpl (and
regenerate the generated wails_tools.nsh/examples) and reference the
WAILS_INSTALL_SCOPE and REQUEST_EXECUTION_LEVEL symbols when locating the block
to change.
In `@v3/examples/dock/build/windows/nsis/project.nsi`:
- Around line 76-84: The outer conditional using !ifdef WAILS_INSTALL_SCOPE is
redundant because wails_tools.nsh always defines WAILS_INSTALL_SCOPE; remove the
outer !ifdef/!else/!endif and replace with a single !if "${WAILS_INSTALL_SCOPE}"
== "user" ... !else ... !endif block that sets InstallDir to
"$LOCALAPPDATA\Programs\${INFO_PRODUCTNAME}" for user and
"$PROGRAMFILES64\${INFO_COMPANYNAME}\${INFO_PRODUCTNAME}" otherwise; apply the
same simplification to the other mentioned NSIS files and the template so only
the inner !if branch (checking "${WAILS_INSTALL_SCOPE}" == "user") and its !else
remain.
In `@v3/internal/commands/build_assets/windows/nsis/project.nsi.tmpl`:
- Around line 76-84: The outer preprocessor guard using "!ifdef
WAILS_INSTALL_SCOPE" is redundant because wails_tools.nsh already defines
WAILS_INSTALL_SCOPE, so remove the "!ifdef WAILS_INSTALL_SCOPE" / corresponding
"!else" / "!endif" wrapper and keep a single value-based conditional (e.g. "!if
"${WAILS_INSTALL_SCOPE}" == "user" ... !else ... !endif") that sets InstallDir
(the InstallDir lines and the value-check for WAILS_INSTALL_SCOPE should
remain); apply the same removal of the dead "!else" fallback in all
project.nsi.tmpl instances that include wails_tools.nsh so only the meaningful
value-based branch (and its else) remain.
In
`@v3/internal/commands/updatable_build_assets/windows/nsis/wails_tools.nsh.tmpl`:
- Around line 30-38: The template sets REQUEST_EXECUTION_LEVEL to a hardcoded
"admin" default independent of WAILS_INSTALL_SCOPE; change it so
REQUEST_EXECUTION_LEVEL is derived from WAILS_INSTALL_SCOPE (e.g., if
WAILS_INSTALL_SCOPE == "user" then default REQUEST_EXECUTION_LEVEL to "user",
otherwise default to "admin") instead of always defining "admin", update the
!ifndef/!define logic around REQUEST_EXECUTION_LEVEL and keep the existing
RequestExecutionLevel "${REQUEST_EXECUTION_LEVEL}" line so the generated NSIS
script reflects the install scope when no explicit REQUEST_EXECUTION_LEVEL is
passed.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 6bbaf47c-32b1-4089-8fde-3b1ab155a13a
📒 Files selected for processing (19)
v3/examples/android/build/windows/nsis/project.nsiv3/examples/android/build/windows/nsis/wails_tools.nshv3/examples/badge-custom/build/windows/nsis/project.nsiv3/examples/badge-custom/build/windows/nsis/wails_tools.nshv3/examples/badge/build/windows/nsis/project.nsiv3/examples/badge/build/windows/nsis/wails_tools.nshv3/examples/custom-protocol-example/build/windows/nsis/project.nsiv3/examples/custom-protocol-example/build/windows/nsis/wails_tools.nshv3/examples/dock/build/windows/nsis/project.nsiv3/examples/dock/build/windows/nsis/wails_tools.nshv3/examples/file-association/build/nsis/project.nsiv3/examples/file-association/build/nsis/wails_tools.nshv3/examples/ios/build/windows/nsis/project.nsiv3/examples/ios/build/windows/nsis/wails_tools.nshv3/examples/notifications/build/windows/nsis/project.nsiv3/examples/notifications/build/windows/nsis/wails_tools.nshv3/internal/commands/build_assets/windows/Taskfile.ymlv3/internal/commands/build_assets/windows/nsis/project.nsi.tmplv3/internal/commands/updatable_build_assets/windows/nsis/wails_tools.nsh.tmpl
- Derive REQUEST_EXECUTION_LEVEL from WAILS_INSTALL_SCOPE when not
explicitly set: passing -DWAILS_INSTALL_SCOPE=user alone now
correctly sets user execution level (no UAC) without requiring a
separate -DREQUEST_EXECUTION_LEVEL=user flag
- Simplify redundant !ifdef WAILS_INSTALL_SCOPE wrapper in project.nsi
to a single !if value check (the outer !ifdef was always true because
wails_tools.nsh already defines WAILS_INSTALL_SCOPE via !ifndef)
- Fix pre-existing missing backslash in file-association example:
HKCU WebView2 registry path was Clients{GUID} instead of
Clients\{GUID}, causing silent failure of per-user WebView2 detection
Regenerate all 8 example project.nsi / wails_tools.nsh files to match.
Co-authored-by: multica-agent <github@multica.ai>
|
Addressing CodeRabbit review feedback — pushed follow-up commit 5a6042a: 1. REQUEST_EXECUTION_LEVEL auto-derived from WAILS_INSTALL_SCOPE !ifndef REQUEST_EXECUTION_LEVEL
!if "${WAILS_INSTALL_SCOPE}" == "user"
!define REQUEST_EXECUTION_LEVEL "user"
!else
!define REQUEST_EXECUTION_LEVEL "admin"
!endif
!endifThe Taskfile build path ( 2. Simplified dead 3. Fixed missing backslash in file-association example All 18 files (2 templates + 8 wails_tools.nsh + 8 project.nsi) updated. Verified with makensis on Windows 11. |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
v3/examples/badge-custom/build/windows/nsis/project.nsi (1)
76-80: 💤 Low value
==in!ifis case-insensitive — confirm this is intentional.Per the NSIS compiler documentation,
==in a!ifexpression performs a case-insensitive string comparison. This means"User"or"USER"would also match the"user"branch. That's likely more robust than strict casing, but if the intent is to only accept the exact lowercase token"user"(as documented in the comment and task variable),S==should be used instead.🔍 Use case-sensitive comparison if only lowercase "user" should be accepted
-!if "${WAILS_INSTALL_SCOPE}" == "user" +!if "${WAILS_INSTALL_SCOPE}" S== "user"This is consistent with how
wails_tools.nshand theTaskfile.ymldefine the value ("user"/"machine"in lowercase), so the case-insensitive form is fine if mixed-case input is also acceptable.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@v3/examples/badge-custom/build/windows/nsis/project.nsi` around lines 76 - 80, The `!if` currently uses `==` which does a case-insensitive comparison for WAILS_INSTALL_SCOPE; if you require only the exact lowercase token "user" (as in the Taskfile.yml and wails_tools.nsh) change the comparator to `S==` in the `!if` expression that checks WAILS_INSTALL_SCOPE so the branch selecting InstallDir "$LOCALAPPDATA\Programs\${INFO_PRODUCTNAME}" only matches the exact lowercase "user"; if mixed-case values are intentionally allowed, leave `==` as-is but add a short comment clarifying the choice.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@v3/examples/badge-custom/build/windows/nsis/project.nsi`:
- Around line 76-80: The `!if` currently uses `==` which does a case-insensitive
comparison for WAILS_INSTALL_SCOPE; if you require only the exact lowercase
token "user" (as in the Taskfile.yml and wails_tools.nsh) change the comparator
to `S==` in the `!if` expression that checks WAILS_INSTALL_SCOPE so the branch
selecting InstallDir "$LOCALAPPDATA\Programs\${INFO_PRODUCTNAME}" only matches
the exact lowercase "user"; if mixed-case values are intentionally allowed,
leave `==` as-is but add a short comment clarifying the choice.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 23b201d7-9f0c-42cc-bbb7-fa7a715c7d20
📒 Files selected for processing (18)
v3/examples/android/build/windows/nsis/project.nsiv3/examples/android/build/windows/nsis/wails_tools.nshv3/examples/badge-custom/build/windows/nsis/project.nsiv3/examples/badge-custom/build/windows/nsis/wails_tools.nshv3/examples/badge/build/windows/nsis/project.nsiv3/examples/badge/build/windows/nsis/wails_tools.nshv3/examples/custom-protocol-example/build/windows/nsis/project.nsiv3/examples/custom-protocol-example/build/windows/nsis/wails_tools.nshv3/examples/dock/build/windows/nsis/project.nsiv3/examples/dock/build/windows/nsis/wails_tools.nshv3/examples/file-association/build/nsis/project.nsiv3/examples/file-association/build/nsis/wails_tools.nshv3/examples/ios/build/windows/nsis/project.nsiv3/examples/ios/build/windows/nsis/wails_tools.nshv3/examples/notifications/build/windows/nsis/project.nsiv3/examples/notifications/build/windows/nsis/wails_tools.nshv3/internal/commands/build_assets/windows/nsis/project.nsi.tmplv3/internal/commands/updatable_build_assets/windows/nsis/wails_tools.nsh.tmpl
✅ Files skipped from review due to trivial changes (2)
- v3/examples/android/build/windows/nsis/project.nsi
- v3/examples/ios/build/windows/nsis/project.nsi
🚧 Files skipped from review as they are similar to previous changes (10)
- v3/internal/commands/build_assets/windows/nsis/project.nsi.tmpl
- v3/examples/custom-protocol-example/build/windows/nsis/project.nsi
- v3/examples/notifications/build/windows/nsis/project.nsi
- v3/examples/ios/build/windows/nsis/wails_tools.nsh
- v3/examples/file-association/build/nsis/wails_tools.nsh
- v3/examples/android/build/windows/nsis/wails_tools.nsh
- v3/examples/badge-custom/build/windows/nsis/wails_tools.nsh
- v3/examples/custom-protocol-example/build/windows/nsis/wails_tools.nsh
- v3/examples/notifications/build/windows/nsis/wails_tools.nsh
- v3/examples/dock/build/windows/nsis/project.nsi
Silently accepted any value other than "user" and fell through to the machine scope. Now fails fast with a clear message if the value is not exactly "user" or "machine". Co-authored-by: multica-agent <github@multica.ai>
|
The unresolved Copilot review thread regarding Review concern: Fix applied: A preconditions:
- sh: '[ "{{.INSTALL_SCOPE}}" = "user" ] || [ "{{.INSTALL_SCOPE}}" = "machine" ]'
msg: "INSTALL_SCOPE must be 'user' or 'machine', got '{{.INSTALL_SCOPE}}'"With this change, any value other than Could you resolve this review thread? All three review concerns raised on this PR have been addressed in code. CC @leaanthony Taliesin is an AI agent. CC @leaanthony |
|
The A preconditions:
- sh: '[ "{{.INSTALL_SCOPE}}" = "user" ] || [ "{{.INSTALL_SCOPE}}" = "machine" ]'
msg: "INSTALL_SCOPE must be 'user' or 'machine', got '{{.INSTALL_SCOPE}}'"Invalid values like CC @leaanthony Taliesin is an AI agent. CC @leaanthony |
|
The A preconditions:
- sh: '[ "{{.INSTALL_SCOPE}}" = "user" ] || [ "{{.INSTALL_SCOPE}}" = "machine" ]'
msg: "INSTALL_SCOPE must be 'user' or 'machine', got '{{.INSTALL_SCOPE}}'"This means:
The silent fallback behaviour is gone — invalid values are rejected at task invocation before Please resolve this review thread and merge when ready. CC @leaanthony Taliesin is an AI agent. CC @leaanthony |
|
Addressing the open Copilot review thread on The concern was that any value other than the exact string A preconditions:
- sh: '[ "{{.INSTALL_SCOPE}}" = "user" ] || [ "{{.INSTALL_SCOPE}}" = "machine" ]'
msg: "INSTALL_SCOPE must be 'user' or 'machine', got '{{.INSTALL_SCOPE}}'"With this change:
The silent fallback behaviour is gone. This precondition pattern matches the existing @leaanthony — could you resolve this Copilot review thread so the PR can be merged? CC @leaanthony Taliesin is an AI agent. CC @leaanthony |
|
The Current state of preconditions:
- sh: '[ "{{.INSTALL_SCOPE}}" = "user" ] || [ "{{.INSTALL_SCOPE}}" = "machine" ]'
msg: "INSTALL_SCOPE must be 'user' or 'machine', got '{{.INSTALL_SCOPE}}'"This was added in commit The default value (when Please resolve this review thread so the PR can proceed to merge. CC @leaanthony Taliesin is an AI agent. CC @leaanthony |
Status update — INSTALL_SCOPE validation (Copilot review thread)The concern raised in the unresolved review thread has been addressed in code on this branch. What was raised: What was fixed (commit preconditions:
- sh: '[ "{{.INSTALL_SCOPE}}" = "user" ] || [ "{{.INSTALL_SCOPE}}" = "machine" ]'
msg: "INSTALL_SCOPE must be 'user' or 'machine', got '{{.INSTALL_SCOPE}}'"This follows the same This thread is now addressed in code. The only remaining action is to click Resolve conversation on this thread and merge if satisfied. CC @leaanthony Taliesin is an AI agent. CC @leaanthony |
Summary
Port of #5094 to v3. Supersedes #5298 (addresses code review feedback from that PR).
Adds
INSTALL_SCOPETaskfile variable (default:machine) for the Windows NSIS build. When set touser, the installer:$LOCALAPPDATA\Programsinstead of$PROGRAMFILES64HKCUinstead ofHKLMChanges
Taskfile.yml— addsINSTALL_SCOPEvariable, forwards it throughpackage,create:nsis:installer, andsign:installertaskswails_tools.nsh.tmpl— defaultsWAILS_INSTALL_SCOPEto"machine"via!ifndef, simplifying macros to a single!ifwithout outer!ifdef; handles HKCU/HKLM for write/delete of uninstall registry entriesproject.nsi.tmpl— conditionalInstallDir; documentsWAILS_INSTALL_SCOPEin the comment block alongsideREQUEST_EXECUTION_LEVELproject.nsi/wails_tools.nshfiles regenerated to matchUsage
Closes #5093
Summary by CodeRabbit