Win installer - add option to install in Current User (default) or All Users

[arnonm]

Add ability to install in Current User w/o Admin rights (default) or to All Users
Can be specificed in command line /CurrentUser or /AllUsers, or via GUI if no command line is given.

The addition of the GUI and Command line require two nsis add-ons which are not available on MacOS, only on Windows, which means the windows executable has to be build on Windows.
Added a flow on windows to build the windows artifact

Currently active on a WinInstaller branch. Leaving it up to the maintainer to decide when this github Actions is called

[buchen]

Hi @arnonm,

let me share an initial reaction.

First, it would be super helpful to squash these many commits into one. That makes it much easier to review. Additionally, it is always helpful if you rebase your contributions instead of merging the upstream master into your branch. Can you be so kind and force push the squashed changes into this pull request?

Second, about the add-ons:

The addition of the GUI and Command line require two nsis add-ons which are not available on MacOS, only on Windows, > which means the windows executable has to be build on Windows.

I was able to build it successfully on macOS.
Can you elaborate which add-ons are not available on macOS?

[INFO] --- exec:3.6.3:exec (build-installer) @ portfolio.product ---
Command line defined: "SOFTWARE_VERSION=0.81.1-SNAPSHOT"
Processing script file: "/Users/asbn/Code/portfolio-currencies/portfolio-product/installer/installer.nsi" (UTF8)

Processed 1 file, writing output (x86-unicode):

Output: "../target/products/PortfolioPerformance-0.81.1-SNAPSHOT-setup.exe"
Install: 3 pages (192 bytes), 1 section (1 required) (4120 bytes), 2151 instructions (60228 bytes), 1676 strings (169466 bytes), 1 language table (230 bytes).
Uninstall: 1 page (128 bytes), 1 section (4120 bytes), 35 instructions (980 bytes), 70 strings (2020 bytes), 1 language table (194 bytes).
Datablock optimizer saved 447507 bytes (~0.3%).

Using zlib compression.

EXE header size:              241664 / 39936 bytes
Install code:                  25102 / 232580 bytes
Install data:              112897057 / 230091038 bytes
Uninstall code+data:            1484 / 2130 bytes
CRC (0x6F5B6F76):                  4 / 4 bytes

Total size:                113165311 / 230365688 bytes (49.1%)

Third, on the Github action workflow.

I am building the release installer locally and signing with my code signing certificate (on a secure stick).
Therefore I do not know how I would be able to sign the executables on the Github server.
Plus I do not want to distribute intermediate installer - not every commit is a valid release.
This is especially important if there are changes to the file structure - which must be backward compatible.
For all this reasons, I am skeptical of a GitHub action workflow that is building the executable. I would prefer to not have that workflow (I understand it is there only because the installer is not building on macOS, but this is - see above - not the issue).

[buchen]

Besides the comments above: I think it is a reasonable feature to allow the users to pick the installation method and have the registry keys written accordingly. Before the recent change it was unfortunate: a user specific location and global keys.

[arnonm]

I stand corrected. It didn't work for me after I added the extensions for commandline and guy, and the documentation pointed to a Windows only solution. You are correct, it works on a mac. I will remove the windows-build.yml from the PR and squash the rest

[buchen]

Moving this pull request to "changes requested":

• squash and rebase the many changes to master
• remove the GitHub workflow
• undo the changes to the pom.xml

[buchen]

I believe this configuration is not needed here.

[buchen]

The problem here is: this section should be skipped either if the installer is not being build (then it cannot be signed) or if the signing is skipped (then we want to skip the signing). Unfortunately, I was not able to figure out how to check for two properties here. And I did not want to introduce yet another combined property.

Therefore one can pick either of both properties. I picked the installer because I (more often) skip the windows installer while still wanting to sign the executable in the update site. I know it can be either/or, but I would prefer not to change this here.

[buchen]

@arnonm, FYI, for readability, I have squashed all commits and force pushed them into the pull request

[buchen]

I propose to uncomment the GrantOnFile.

[buchen]

I understand that the plugin is not available in a standard NSIS installation. It needs to be installed.

The purpose is this: if the application is installed into the system location, then the self-update of Eclipse needs the additional permissions. I added this a long time ago because otherwise users get error messages when updating the installation.

My thinking is: we can "just" keep it here as it is. Why? If the user installs for "All users", then he must already have the permission to run GrantOnFile. If the user installed for the current user only, it is not really needed, but it also does not make a difference if it is called.

What do you think?

[buchen]

@arnonm ?

[arnonm]

I agree. It is not worth the overhead of installing the additional plugin