Support wizard installer on Windows

[caesay]

The current installer for windows is a one-click installer which has very minimal UI.

It is desirable for some developers to provide an installer which allows the user to customise install location, install optional features, windows services, license acceptance dialogs, and so forth.

On MacOS, the built-in .pkg installer has a lot of this already, so this task would bring windows back up to feature parity with macos. The one-click installer should still be the default, but the solution here would allow a developer to customise the installer further.

Ideally, we will integrate with NSIS or WiX to provide the wizard installer, but since those are very complex tools, we should distil the user experience down to a limited subset of common features and make it very easy to use.

Some possible configuration options:

• Where to install the application eg. appdata, or program files, or custom user choice
• Custom rtf/html/markdown pages (macos supports welcome, readme, license, conclusion).
• Features: This needs some more thought. Perhaps to start out with we can support Windows Services as a required or optional feature. Later down the line, maybe custom features can invoke an exe with the usual --install hook. The benefit of this hook as a "feature" rather than the regular hook is that this could be run in a privileged context.
• ~~Firewall rules~~ (don't think this is in scope for this issue)
• ~~Where to allow installing shortcuts to, and whether to allow user choice~~ ✔ This is now supported in the one-click installer.

To support updating installs in privileged folders, the updater also needs to know how to prompt for UAC if we hit an access denied error. To support updating windows services, the updater will need to know how request UAC and to stop/start a service.

Since some people need to deploy msi's via group policies / wsus, we should also endeavor to make this wizard installer emit an .msi.

[Tommo56700]

Any updates on this? My company has a strict policy blocking users from running exe’s from AppData to reduce malware risk and prevent users from circumventing admin privileges. So we must install to ProgramFiles. How would the auto update work if this was the case?

[remco1271]

You could put the portable version in the ProgramFiles and give users write permission to that one folder to allow it to update. Custom location was also requested at #177

[caesay]

I am sorry there is no update on this issue yet. Velopack does not support updating in program files yet.

[plumenator]

Any chance I can contribute here? I'd love to, but I confess would need some pointers to start.

[Keboo]

Any chance I can contribute here? I'd love to, but I confess would need some pointers to start.

This is actually something that we are actively working on implementing. If you want to see where we are at, it will likely be a topic discussed on my twitch live stream (starting soon).

[TSelbonne]

I was having the same issue, a workaround I have found is to create a shortcut to the setup.exe and add the parameter -t or --installto as per setup.rs

.arg(arg!(-t --installto <DIR> "Installation directory to install the application").required(false).value_parser(value_parser!(PathBuf)))

[Anequit]

Will the --installto argument allow us to install into a subfolder in appdata?

Something similar to: %appdata%/company/Product

[pfeigl]

This is something we would be very intrested too. The two major usecases for us are

• Installing into a org based folder structure as @Anequit also asked for
• Defining custom installation directories while packing the application. This would allow us to have seperate installers for Test / Prod and so on. We are intentionally not working with channels and need to have different installers per environment