You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
pronebird
changed the title
[feat] nsis: provide customization for default installer.nsh
[feat] nsis: provide customization for default installer.nsi
May 6, 2024
pronebird
changed the title
[feat] nsis: provide customization for default installer.nsi
[feat][v2] nsis: provide customization for default installer.nsi
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:
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.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:CheckIfAppIsRunning
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 intoinstaller.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
The text was updated successfully, but these errors were encountered: