Electron-builder: NSIS Installer Not Working on Second Invocation

[Joshua-Smith]

• Version: 6.3.5

• Target: Windows

I am building a oneClick:true NSIS installer with perMachine:true.
If I run the installer on a clean machine, it works perfectly.
If I uninstall then run the installer again, it works perfectly.
But if I run the installer when there is a previous (or even exactly the same) app installed, it only installs some of the files.

First run:

 Directory of C:\Program Files\Tour

09/02/2016  12:26 PM    <DIR>          .
09/02/2016  12:26 PM    <DIR>          ..
09/02/2016  11:42 AM            58,177 blink_image_resources_200_percent.pak
09/02/2016  11:42 AM                15 content_resources_200_percent.pak
09/02/2016  11:42 AM         9,852,761 content_shell.pak
09/02/2016  11:42 AM         3,466,856 d3dcompiler_47.dll
09/02/2016  11:42 AM         1,942,528 ffmpeg.dll
09/02/2016  11:42 AM        10,127,152 icudtl.dat
09/02/2016  11:42 AM            80,896 libEGL.dll
09/02/2016  11:42 AM         2,222,592 libGLESv2.dll
09/02/2016  11:42 AM             1,075 LICENSE
09/02/2016  11:42 AM         1,376,928 LICENSES.chromium.html
09/02/2016  11:42 AM    <DIR>          locales
09/02/2016  11:42 AM           394,778 natives_blob.bin
09/02/2016  11:42 AM        12,962,304 node.dll
09/02/2016  11:42 AM    <DIR>          resources
09/02/2016  11:42 AM        62,150,104 Tour.exe
09/02/2016  11:42 AM           643,204 snapshot_blob.bin
09/02/2016  11:42 AM            82,388 ui_resources_200_percent.pak
09/02/2016  11:42 AM           152,032 Uninstall Tour.exe
09/02/2016  11:42 AM            59,985 views_resources_200_percent.pak
09/02/2016  11:42 AM            81,768 xinput1_3.dll
              18 File(s)    105,655,543 bytes
               4 Dir(s)  121,922,035,712 bytes free

Second Run:

 Directory of C:\Program Files\Tour

09/02/2016  12:32 PM    <DIR>          .
09/02/2016  12:32 PM    <DIR>          ..
09/02/2016  11:42 AM         3,466,856 d3dcompiler_47.dll
09/02/2016  11:42 AM         1,942,528 ffmpeg.dll
09/02/2016  11:42 AM            80,896 libEGL.dll
09/02/2016  11:42 AM         2,222,592 libGLESv2.dll
09/02/2016  11:42 AM        12,962,304 node.dll
09/02/2016  11:42 AM        62,150,104 Tour.exe
09/02/2016  11:42 AM           152,032 Uninstall Tour.exe
09/02/2016  11:42 AM            81,768 xinput1_3.dll
               8 File(s)     83,059,080 bytes
               2 Dir(s)  121,945,260,032 bytes free

Third run:

 Directory of C:\Program Files\Tour

09/02/2016  12:32 PM    <DIR>          .
09/02/2016  12:32 PM    <DIR>          ..
09/02/2016  11:42 AM         3,466,856 d3dcompiler_47.dll
09/02/2016  11:42 AM         1,942,528 ffmpeg.dll
09/02/2016  11:42 AM            80,896 libEGL.dll
09/02/2016  11:42 AM         2,222,592 libGLESv2.dll
09/02/2016  11:42 AM    <DIR>          locales
09/02/2016  11:42 AM           394,778 natives_blob.bin
09/02/2016  11:42 AM        12,962,304 node.dll
09/02/2016  11:42 AM    <DIR>          resources
09/02/2016  11:42 AM        62,150,104 Tour.exe
09/02/2016  11:42 AM           643,204 snapshot_blob.bin
09/02/2016  11:42 AM            82,388 ui_resources_200_percent.pak
09/02/2016  11:42 AM           152,032 Uninstall Tour.exe
09/02/2016  11:42 AM            59,985 views_resources_200_percent.pak
09/02/2016  11:42 AM            81,768 xinput1_3.dll
              12 File(s)     84,239,435 bytes
               4 Dir(s)  121,711,751,168 bytes free

I don't know how to turn on installer logging, or if it is on, I don't know where to find the logs. So if you could give me a pointer for that, I might be able to get more data.

Other things which might be relevant:

• Doing the build on a Mac
• Signing everything
• Running installer on Windows 7 in a Parallels VM (so it's single-CPU and not fast)
• I had this issue with 6.3.1 also, but not 5.x (before oneClick existed)
• I had this issue building perMachine:false as well
• Same issue if I set oneClick:false and use the boring installer
• Custom script being included to setup protocol handler (replace __scheme__ with my actual scheme):

!macro customInstall
  DetailPrint "Register __scheme__ URI Handler"
  DeleteRegKey HKCR "__scheme__"
  WriteRegStr HKCR "__scheme__" "" "URL:__scheme__"
  WriteRegStr HKCR "__scheme__" "URL Protocol" ""
  WriteRegStr HKCR "__scheme__\DefaultIcon" "" "$INSTDIR\${APP_EXECUTABLE_FILENAME}"
  WriteRegStr HKCR "__scheme__\shell" "" ""
  WriteRegStr HKCR "__scheme__\shell\Open" "" ""
  WriteRegStr HKCR "__scheme__\shell\Open\command" "" "$INSTDIR\${APP_EXECUTABLE_FILENAME} %1"
!macroend

[Joshua-Smith]

I tried stuffing !verbose 4 into install.sh to see if I could find any more clues, but I can't figure out where NSIS writes the install log. Do you have any idea?

Or does that just set the verbosity of the NSIS compiler and have nothing to do with runtime?

[develar]

Known issue, I tried to fix it, but as I see, it is still not fixed. I am investigating.

[develar]

http://forums.winamp.com/showpost.php?p=3067941&postcount=69

[Joshua-Smith]

Anything I can do to help, let me know. This is a blocking issue for me. Things that haven't helped:

• Changing compression level to "stored"
• Running installer /S
• Adding a 10 second Sleep at the end of installation
• Run as Admin

[develar]

@Joshua-Smith Is app started on finish in any case or not?

[develar]

Solution will be implemented before Monday — as a temp workaround external unarchiver will be used.

[develar]

Am I right, that is not reproducible on Windows 10 real machine?

[Joshua-Smith]

It tries to start the app when it finishes, but of course the app crashes since so many DLLs and configuration files are missing.

I haven't tried it on a real Windows 10 machine. I can do that on Tuesday if it would be helpful. All I have VMs for right now are windows XP, 7, 8, 8.1.

[develar]

Please try 6.4.1.

[Joshua-Smith]

sudo npm install electron-builder -g just brought me up to 6.4.0. What's the trick to get 6.4.1?

[develar]

Set version to next

[develar]

npm install electron-builder@next

[Joshua-Smith]

Now we have two problems.

1. The installer creates an extra folder named by the build number, which causes strange results.
2. If I uninstall and then do a clean install it works. But running the installer again gives the same result as before. Even though the progress bar shows it did all the installation, it doesn't.
   I have a theory: Do you uninstall the old files? If so, is it possible that the uninstaller is _still running_ when the install is happening, and it is deleting files after you unpack them???

[develar]

The installer creates an extra folder named by the build number, which causes strange results.

Since Windows *, I decided to create extra folder to be sure that old version doesn't block files and new version can be installed correctly even if old version files cannot be deleted.

I have a theory: Do you uninstall the old files? If so, is it possible that the uninstaller is still running when the install is happening, and it is deleting files after you unpack them???

It is not possible, but since it is windows, everything is possible. Ok.... I give up — I will prepare soon version where external 7za is used instead of internal NSIS plugin.

Please note — I am sure that end users are not affected currently because now we use extra folder per version.

[Joshua-Smith]

My users regularly run the same installers more than once. I have a user base who often doesn't understand the difference between an installer and a program, for example. So actually, this could impact end users. Having multiple versions of the program hanging around in that program files folder is not a good idea at all. There will either be multiple versions listed in "Add or Remove Programs" or maybe worse, there will be no way to uninstall an old version. I'd strongly recommend you back out of that extra directory. Or at least give me an option to not have that behavior for my installer, because it's going to cause a lot more problems than it solves.

[develar]

There will either be multiple versions listed in "Add or Remove Programs" or maybe worse, there will be no way to uninstall an old version.

No. We always uninstall old version before install.

or maybe worse, there will be no way to uninstall an old version.

You can always open uninstaller directly using File Explorer. Even if uninstaller entry will be removed from windows registry.

Squirrel.Windows also uses this scheme to install.

So, is there any other strong objection? No doubt — I understand you, I just want to be sure.

[Joshua-Smith]

Some of my users don't know how to use the file explorer :).

If you run the uninstall before the new install, that would seem to solve the issue I'm concerned about. So I guess that's not a problem.

Are you positive it isn't that the old uninstaller is still running while the installer is unpacking files? Since the uninstaller is a separate process, it would totally explain the behavior we are seeing.

[develar]

that would seem to solve the issue I'm concerned about.

So, I will not revert this change. To be clear — Window IO is *, so, using another dir for version is more robust. Auto-update will be implemented soon and Windows can block old files — to avoid it, and to be sure that new version NEVER uses old files, this scheme (folder per version) is implemented.

Since the uninstaller is a separate process, it would totally explain the behavior we are seeing.

ExecAndWait is used. I will test it again to be sure — is it NSIS 7z plugin or RMDir /r nsis issue.

[Joshua-Smith]

Okay on the not reverting. I see your point totally.

I tried an experiment where I pulled the Unintaller out of the Program Files folder and then run the installer. I did it twice and both times the install works. I'll do a few more tries, but it seems to solve the issue. The uninstaller copies itself to a temporary place and then runs that. So maybe ExecAndWait is only waiting for the first half of that process.

[Joshua-Smith]

Check it out. The task manager shows the uninstaller is still running, yet the progress bar is at 20%.

[Joshua-Smith]

http://nsis.sourceforge.net/When_I_use_ExecWait_uninstaller.exe_it_doesn't_wait_for_the_uninstaller

[Joshua-Smith]

http://stackoverflow.com/questions/3256834/how-to-wait-for-uninstaller-to-finish

[develar]

Thanks! I will fix it tomorrow morning CET. Please note — as far I understand, we cannot just use _?=$INSTDIR to disable temporary copy, because we need to delete uninstaller. Instead, we should copy it to temp ($PLUGINSDIR) and then run with this arg.

[develar]

http://stackoverflow.com/questions/24595887/waiting-for-nsis-uninstaller-to-finish-in-nsis-installer-either-fails-or-the-uni

[Joshua-Smith]

This bug has returned in 6.7.4. If I run the new installer twice, the second time I end up with only half the files because the uninstaller is still running while the files are being copied in.

I'm almost completely certain this is a regression in 6.7.4 and this was fix in 6.7.2.

[develar]

@Joshua-Smith Cannot believe :(

[Joshua-Smith]

This is probably caused by the uninstaller being invoked with the arguments in the wrong order. See related comment on #735

[Joshua-Smith]

Confirmed that this problem is no longer present in 6.7.7. Thank you!