Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NSIS autoupdate behavior issue #1106

Closed
sagorshkov opened this issue Jan 12, 2017 · 13 comments
Closed

NSIS autoupdate behavior issue #1106

sagorshkov opened this issue Jan 12, 2017 · 13 comments

Comments

@sagorshkov
Copy link

  • 11.2.4:
  • Windows:

Hello. I think There is a bug in the NSIS autoupdate feature. One of latest features is "allowToChangeInstallationDirectory". When downloaded new app version using autoupdate this version will be unpacked in the default AppData/Local/AppName folder, but not to custom directory where was installed the first version. In the first version's directory, all files will be removed.

Also, I notice next behavior. When new update correctly downloaded and we execute autoUpdater.quitAndInstall() will be started NSIS installer which was downloaded. We can install this update to new directory!!!!! But if we do not execute this method and simply close application, the update will be unpacked in the background and next time will be started new version of the app. Is it correct behavior for NSIS? Is it possible simply shut down an app, unpack the update to the current app folder, and start the app again?

Thak you in advance.

@develar
Copy link
Member

develar commented Jan 12, 2017

update will be unpacked in the background and next time will be started new version of the app. Is it correct behavior for NSIS

In any case auto-update installer must show the same installer as on install. It is bug.

Is it possible simply shut down an app, unpack the update to the current app folder, and start the app again?

It works so, but it seems, now it is broken.

but not to custom directory where was installed the first version

Old app installer deletes all entries from registry and user have to choose inst dir again. Well, due to other bug currently auto-update installed in a silent mode.

I hope I will find time to fix it this week.

@develar
Copy link
Member

develar commented Jan 12, 2017

@sagorshkov Please see #884 (comment) Do you listen update-downloaded? Do you call autoUpdater.quitAndInstall()?

@sagorshkov
Copy link
Author

@develar Yes of course. I'm executing autoUpdater.quitAndInstall() only when "update-downloaded" event is emitted. I remember when I was executing this method with Squirrel the app was closed, the update was unpacked and new app was started automatically. But not with NSIS((( Should user install app again with NSIS? Or it is possible to do update in the background in the same directory where was the last version and simply start app again?

@develar
Copy link
Member

develar commented Jan 12, 2017

Or it is possible to do update in the background in the same directory where was the last version and simply start app again?

As stated, it should work so, but now is broken. It will be fixed today or tomorrow.

@develar
Copy link
Member

develar commented Jan 14, 2017

1.0.0 works for me — installer window is displayed. Case "allowToChangeInstallationDirectory" will be checked soon.

@sagorshkov
Copy link
Author

Hello @develar
I continued my NSIS testing and noticed a few issues (it's possible bugs):

  1. The most important for me: if install build for all users (perMachine) the auto update not work. It deletes the desktop icon but not files in default folder (it's Program File/App Name becouse I cant use allowToChangeInstallationDirectory because of a bug I've described above). When the app starts again it's old version and the 'update-downloaded' emits again. Everything is repeated in a circle.
  2. If build was installed for all users (perMachine), Uninstall not work. But it works if we uninstall the app via Programm and Components.
  3. If "oneClick" is false and we try to install the app for all users (perMachine), allowElevation (it's true as default) emit and we will see the yes/no dialogue. But when we click yes the final window is showing (with start app right now checkbox). But there are not enough files in the app folder.

My app will be released in nearest future and I very much would like to use NSIS instead Squirrel((( Could you please shed any light on your plans about the NSIS fixes? Thanks in advance...

@develar
Copy link
Member

develar commented Jan 24, 2017

I started work on #1129 — I will check auto update for per machine installers. Feel free to ping me in 2 days if I will not report progress here.

@sagorshkov
Copy link
Author

@develar I check the second case in my previous message.

  1. If build was installed for all users (perMachine), Uninstall not work. But it works if we uninstall the app via Programm and Components.

The "Uninstall" in the app directory not prompt the Admin's privileges It's why it not work. It's why in not work. At the same time, Programm and Components ask Admin's privileges and Uninstall works correctly. Probably this link will be useful.

About

  1. If "oneClick" is false and we try to install the app for all users (perMachine), allowElevation (it's true as default) emit and we will see the yes/no dialogue. But when we click yes the final window is showing (with start app right now checkbox). But there are not enough files in the app folder.

I,ve tested it. It looks like after the Admins prompt was confirmed the app starts to install in the background. But the final window (with Run app right now checkbox) show immediately. If we close the Installer (click Finish) there will be not full files package it the app directory (Only those that had time to unpack). If don't close the installer window enough time the full app will be unpacked (Desktop icon will create even). Looks like mistake in installation steps in this case (installing progress bar is skipping).

Also, I've noticed next behavior. I've set my appId in package.json as something like "com.appname.mac", also there is "name": "AppName" in package.json. But after app installation in the Windows Registry I found my app as "4f53adaa-a4b2-50c1-b605-e304e4d14011". I've seen this. Is it correctly generetion? If I use nsis.guid as "AppName" the Registry keys will be "AppName". I think Registry key "AppName" is better than terrible hash (or something). Should I use GUID for it?

Thanks for fix #1129 I'll test it today.

Thanks for your work)))

@develar
Copy link
Member

develar commented Jan 26, 2017

I hope that most of the UAC related issues were fixed in the 12.0.0. I will check and verify this issue soon (thanks for clear reports). Why I decided to fix bunch of other issues instead of fixing this urgent? Because UAC logic is the reason and should be fixed at first :)

@develar
Copy link
Member

develar commented Jan 29, 2017

GUID allows us to be sure that will be no name clash, so, or is better to use it.

@develar
Copy link
Member

develar commented Jan 29, 2017

  1. The most important for me: if install build for all users (perMachine) the auto update not work

perMachine: true fixed and confirmed in the 12.0.0 / electron-updater 1.2.0.

@develar
Copy link
Member

develar commented Jan 29, 2017

Should be ok in the 12.0.3 / electron-updater 1.3.1

@zhpeng8775
Copy link

Hello @sagorshkov
image

I have the same issue.
the issue has been fixed or not?
If fixed,which version of electron-builder can be usesd.

Thank you in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants