MSI

[ghost]

• Version: 6.3.5

• Target: Windows

A customer is asking for an MSI installer, instead of NSIS. I see that Squirrel can do that, but that means adding support for Squirrel to my app which looks like a major ordeal. (For Windows; adding it for Mac looks trivial.) Is there another option someone can recommend for making a MSI installer? I found msi-packager which relies on another thing msi-tools. Is that a good place to start? Any other recommendations? My build environment is Mac, so if I can avoid having to use Windows to do this, that would be a huge plus.

[develar]

Please see #660 (comment)

Is that a good place to start

No. 100 lines of code and electron-builder will build msi for you. BUT! I am totally unaware of MSI. Can you help and prepare PR to wrap NSIS installer as MSI?

[develar]

@DavidDurman Have you found solution?

[ghost]

I'm totally clueless myself. I just know that one of my enterprise customers doesn't let their people install software on their machines, and want an MSI so they can install it centrally. That EXE->MSI converter he references on the other thread might be a viable workaround for me. It's a drag to have to use Windows, but only one customer is asking for this, and I don't build new installers very often anyway.

[DavidDurman]

@develar I ended up using the NSIS build and wrapped it using the exemsi wrapper: http://www.exemsi.com. It works just fine for me.

[develar]

@naderhen and others — I don't have time to implement it for now. And because it is MS target that will use tool from MS — I need vomit bag to work on this. No plans for now to implement this target. If you want to help — I can guide you and help to write new target for electron-builder (use slack direct messages).

[nzubair]

And because it is MS target that will use tool from MS

Not necessarily. There is always WiX Toolset (http://wixtoolset.org/ or https://github.com/wixtoolset/ )

[develar]

WiX Toolset

I have touched it. Please kill me. Kill me. I don't want to remember about this experience. People in a psychiatric hospital will be your best friends after using it.

[okonon]

this feature would be a killer!

[Ajeey]

@DavidDurman Does auto update work when you wrap NSIS build in http://www.exemsi.com?

[okonon]

I would like to know as well

[develar]

Reopened - there is a chance that I will fix it in a near future.

[Ajeey]

@develar Thank you. :)
What approach are you going to use, exemsi or wix?

[develar]

There is no choice. I am not insane to use MS tool to build MSI. I doubt that exemsi company will offer us acceptable for electron builders users conditions. Also, exemsi requires net. So, only wix.

[Ajeey]

@develar hmm okay. Also coming to my question, when you wrap nsis build into msi installer via wix, would the auto updater(https://www.electron.build/auto-update) work out of the box?

The reason I am asking is, if auto update works out of the box, I can go ahead and spend some time on the wix installer.

[develar]

@Ajeey In general, should work. But because it is Windows — need to test to be sure.

[okonon]

Recently corporate clients started to look for cross platform solutions. And 90% of them are MS based shops. I think there is huge potential to support Windows.

[develar]

It will be useful if you can name some reasons why MSI is required.

[okonon]

I do not think it is required, it would be nice to have that feature but not a show stopper.
In my experience good amount of companies are very opinionated regarding distributing software to their employees. It allows companies to have more control over a program (remotely push to many users, uninstall, etc) that was distributed via windows policy for example. I am a Mac fan myself and have strong opinion about Windows to but in corporate world Windows is still dominating at the moment.
Hope that helps

[nzubair]

As @okonon said, most medium to large sized corporate environments have their own software installation & distribution policies. MSI is generally easier to work with when deploying to a large number of targets. And yes, it's not required, but nice to have.

For most people managing the software distribution, they're already familiar with how MSI works. As opposed to working with a new installer, which would involve things like:

• Test and figure out how the new executable behaves (for me, NSIS uninstaller was triggering our anti-malware systems)
• What the parameters are to silently install and uninstall it.
• Are the install and uninstall processes clean and do they interfere with anything else on the system.

[ghost]

Since I started this thread, please pardon the slight non-sequitur. I recently had a customer who needed one of our apps to run on a Surface Hub. That's a big locked-down touchscreen Windows 10 thing that will only run pure Windows 10 apps. Turns out that an Electron app converted to Windows Store using the Universal Converter thingy does not qualify. So in the end, I reworked that particular app to eliminate any Node dependencies, and added a few Windows-specific javascript API calls in their place. There are two ways to do it. You can either host your app on the web and put a little wrapper in the store, or you can bundle all the HTML5/CSS3/JS together and put the thing in the store en-masse (I did the latter). The end result is a nifty little installer that enterprises that have moved to Windows 10 will probably like better than an MSI. It's not a direct solution to this problem, but it's a simple solution when your app (like mine) is 99% web app anyway.

[develar]

Target mostly done (per-machine one-click installer and assisted installer), but not yet production ready (icons (f*** WiX, why icon cannot be extracted smartly as NSIS does?)) and shortcuts are not created).

Therefore, if you need MSI for your app, please comment in this issue what exactly do you need: one-click or assisted, per-user or per-machine, with eual or without eula.

[Ajeey]

@develar one-click, per-machine & without eula :)

[develar]

MSI one-click, per-machine & without eula supported.

You can build on macOS without installing any additional tools, but only uncompressed and unsigned MSI.

On Linux the same as on macOS (but not tested).

On Windows you can build MSI without installing any additional tools.

[develar]

Now (19.42.1) MSI is a single package authored. It means that MSI can be installed or per-user or per-machine. By default per-user. If need, unset MSIINSTALLPERUSER property.

msiexec /i C:\Example.msi MSIINSTALLPERUSER=""

[develar]

I tried numerous times to avoid "WiX sucks" but... yeach. Future of "assisted installers" is frozen. Bloody WiX cannot correctly set MSIINSTALLPERUSER (and official dialog simply broken and not Windows 7 aware / single package authoring aware).

If you are WiX expert — set

 msi: {
      "oneClick": false,
    },

and investigate why, why, why, why,

<!-- F*** WiX - it doesn't work. Installed per-user in any case. -->
<Publish Property="MSIINSTALLPERUSER">1</Publish>

doesn't work. See WixUI_Assisted.wxs.

[raquila]

Is electron-updater and S3 publishing supported with msi option?

[leekevinyg]

@raquila according to the release notes when this was implemented, auto-update was not supported (see notes under 19.41.0): https://github.com/electron-userland/electron-builder/releases?after=v19.42.2

[lowkay]

I have been investigating getting auto-update to work with MSIs, there doesn't seem to be any technical blocker to this if you're using a per-user installation.

Essentially I created an MsiUpdater that runs msiexec /i <path-to-downloaded-msi>

Then the MsiTarget needs to be updated to publish the update info by specifying isWriteUpdateInfo: true.

I'm in the process of forking and creating a pull request for this - @develar before I spend time doing this, is there another reason why this hasn't been done?

[develar]

MSI for companies to do massive deployments and central management. MSI is dead and bad. No reasons to use it if you can use NSIS.

[akashnimare]

Quick question about the MSI installer -
Is it possible to uninstall the older version of the desktop app (which is NSIS) if I install the app using the MSI installer?

This uninstall perfectly work in case of NSIS target.

Use case -

A client have installed the app using the .exe file of my app (NSIS target) but now that we have also shipped MSI, he has switched to MSI but now there are two apps installed in his system.

[methodbox]

MSI for companies to do massive deployments and central management. MSI is dead and bad. No reasons to use it if you can use NSIS.

What if that's your exact use case? This is an extremely ignorant and dismissive answer that doesn't solve any problems.

[prabhatsaini91]

Electron builder with {target: "msi"} still builds a per-user installer for MSI. There's no way of setting a per-machine installer in MSI.

[shrinidhi111]

Does msi package support auto updates too?

[aplum]

@develar (#723 (comment)) I fixed it! PR #6550.

That PR is substantially different though, so here's what was happening with the current assisted installer. The minimal fix would have been to add <Publish Property="ALLUSERS" Value="2">1</Publish> above this line and change Sequence="1" to After="MigrateFeatureStates" here.

Setting ALLUSERS=2 again was necessary because it was getting changed by Windows Installer (🤷‍♂️), but the tricky one to figure out was changing the dialogs to show after (not sure exactly which action, but I think) CostFinalize instead of being the first action.

With the dialogs happening too early, it was almost working. The desktop shortcut was being installed per-machine, but the app was still installed per-user. This made some sense, after looking at the logs: APPLICATIONFOLDER was set client-side to the per-user location and was not getting updated after ALLUSERS/MSIINSTALLPERUSER changed, and being a public property was passed to server-side. DesktopFolder, being a private property, was not passed from client to server and so was being set correctly server-side based on the new ALLUSERS/MSIINSTALLPERUSER values.

So… possible solution: change APPLICATIONFOLDER to AppFolder (i.e. make it private). It works! But now the installation folder can't be customized from the CLI (msiexec ... APPLICATIONFOLDER="C:\myapp\"), it won't work with standard WiX dialogs, and Microsoft's example MSI (file) works and uses a public property. Could have still made it customizable using a Custom Action, but that all didn't seem right.

Eventually I tried changing the InstallUISequence based on Microsoft's example (and suggested sequence), and it started working. APPLICATIONFOLDER was getting reset client-side after changing ALLUSERS/MSIINSTALLPERUSER, so it was the already correct value when passed to the server.