Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feat][v2] nsis: provide customization for default installer.nsi #9668

Closed
pronebird opened this issue May 6, 2024 · 0 comments · Fixed by #9731
Closed

[feat][v2] nsis: provide customization for default installer.nsi #9668

pronebird opened this issue May 6, 2024 · 0 comments · Fixed by #9731

Comments

@pronebird
Copy link
Contributor

pronebird commented May 6, 2024

Describe the problem

Hi,

Currently I need to bundle a few workspace binaries with my app and execute a few custom commands during installation, at the following stages:

  • Preinstall: before installing the app I run nsExec::ExecToLog to stop/unregister the existing windows service. Typically on Windows, a binary with a running process cannot be replaced. Killing the process before replacing the binary is necessary.
  • Postcopy: running a script to register or update windows service configuration once all files are copied, so I can execute a helper executable copied into the install dir. Then starting the service.
  • Preuninstall: stop and delete windows service. This is again, necessary in order to delete the binary that typically executes as a windows service in background.

This is impossible without copying a rather complex 800 LOC installer.nsi template from tauri and modifying it. However this crates a situation where I have to keep my custom installer script up to date and synchronize changes to the default template (i.e perhaps improvements and bug fixes). Since the file is large enough, this creates a lot of hurdle.

Describe the solution you'd like

I think it would be reasonable to have extend NSIS configuration and alternatively provide NSIS scripts injected into the installer.nsi template. As I described above I think having three different phases is ok, i.e:

  • Preinstall - called after CheckIfAppIsRunning
  • Post-copy - called after copying all files.
  • Preuninstall - called after CheckIfAppIsRunning

I think a reasonable way to handle this would be to provide the installer with a single installer-hooks.nsh (optional) that can be injected into installer.nsi. The hooks script could expose three functions (or macro?) that will be called at different stages of installer lifecycle.

Alternatives considered

No response

Additional context

No response

@pronebird pronebird changed the title [feat] nsis: provide customization for default installer.nsh [feat] nsis: provide customization for default installer.nsi May 6, 2024
@pronebird pronebird changed the title [feat] nsis: provide customization for default installer.nsi [feat][v2] nsis: provide customization for default installer.nsi May 6, 2024
amrbashir added a commit that referenced this issue May 9, 2024
lucasfernog added a commit that referenced this issue May 25, 2024
* feat(nsis): support installer hooks

closes #9668

* update change files

---------

Co-authored-by: Lucas Nogueira <lucas@tauri.studio>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant