Can't run installer on Windows 10

[valeriansaliou]

Hello,

Looks like MSI installers generated from msi-packager are broken on Windows 10 (x64).
MSI files are built from MacOS, via msitools.

It launches, and shortly after pops up the following message:

"error attempting to read from the source install database"
"C:/Windows/Installer/32ea2.msi"

Anything that's not compatible on your side? Or maybe that comes from msitools?

Here's our build config:

    gulp_create_msi({
      source       : (
        "./build/misc/binaries/" + CONFIG.ELECTRON.VERSION + "/win32-x64/"
      ),

      output       : "./build/misc/releases/windows/Crisp.msi",
      name         : "Crisp",
      upgradeCode  : CONFIG.ELECTRON.WINDOWS_MSI_GUID,
      version      : "1.0.0",
      manufacturer : "crisp.im",
      iconPath     : (CONFIG.ENV.SOURCES + "/misc/electron/icons/icon.ico"),
      executable   : "Crisp.exe",
      description  : "Crisp Windows",
      arch         : "x64",
      localInstall : true
    }

Thanks for the great work!

[mmckegg]

Hmm, interesting. No idea what is causing this, but it is most likely something to do with msitools. Unfortunately I don't have access to a Windows 10 machine.

If you figure out anything more, please let me know!

[mmckegg]

Possibly relevant: http://stackoverflow.com/questions/16901722/error-attempting-to-read-from-the-source-install-database-c-windows-installer

That error means the MSI (or some previous version with the same ProductCode) was installed on the machine but the cache was destroyed. I've seen this when people msizap (or use the poorly named FixIt tool from Microsoft) to try and yank an MSI off the machine. If msizap was used, the safest thing for testing purposes is to format the machine and start over.

If formatting the machine is not possible (or msizap was not used) then try recache/reinstalling the new MSI to try and get the source cache patched up. You can do this using the command-line:

msiexec /i new.msi /l*v log.txt

That will cause the new.msi to be cached where the old MSI should have been then repair the machine trying to get it into a consistent state.

[valeriansaliou]

@mmckegg Thanks for the quick response :) I'll check that out and let you know if there's anything to patch back in msi-packager. Probably just a switch in our ProductCode yeah.

[valeriansaliou]

Just tested from a fresh MSI build w/ a new GUID, and the error is the same when running the installer. Isn't that due to the fact we build it from a Mac w/ msitools from brew?

[mmckegg]

In that case, then yes, most likely msitools fault. It could be something in the config I'm generating, but can't think of anything off hand.

[valeriansaliou]

Does it work for you if you try building an MSI w/ the latest msitools dep?

[owenayres]

MSI generated on Mac OS X 10.11.5. Uses the NPM package with msitools installed via brew too. Then ran on a VM running Windows 10, it worked as expected. Just posting this incase others have immediate concerns - not sure what the issue is, but it hasn't effected me thankfully (as of yet)!