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.
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::ExecToLogto 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.nsitemplate 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.nsitemplate. As I described above I think having three different phases is ok, i.e:CheckIfAppIsRunningCheckIfAppIsRunningI 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