One note to add to docs maybe

[matthew-dean]

One thing that just tripped me up - The executable on Windows has to be compiled for the same processor platform as your NW.js. (Or, at least in my case, the 64-bit updater couldn't rename the folder for a 32-bit app.) Otherwise you'll get an "access denied" error.

[oaleynik]

@matthew-dean well, that sounds strange. Right next to the updater you should find the log file. Any chance you can attach it?

[matthew-dean]

Hmm.... it deleted the old log file when I got it working again. (Might be a reason to keep the log around, 😉 ). IIRC, it failed on the step of renaming the folder C:\Program Files (x86)\My App.... orrr... failed on renaming C:\Program Files (x86)\My App.bak with "Access Denied".

[oaleynik]

@matthew-dean any chance the process under My App folder was still running when you started the updater? Or any other files inside of the folder (maybe some code pieces were opened in some text editor)? Main application instructs updater where it is located right before of the updater job. To be honest (I can be wrong) I don't see any correlation between the binary architecture and the error that you have seen...

[oaleynik]

@matthew-dean I found an interesting comment - https://www.quora.com/How-do-some-programs-on-Windows-auto-update-like-Chrome-and-others-dont-like-iTunes/answer/Jeff-Dickey. I actually have the same kind of thinking that apps, built with NWJS/Electron alike platforms should live in the "user space" too.

[oaleynik]

One more thing I've found interesting https://fman.io/blog/google-omaha-tutorial/ (the last paragraph):

Omaha's update task may run at any time, in particular while an instance of your app is running. When an update needs to be performed, you usually cannot simply overwrite your app's files while it is running. To address this issue, we recommend creating a separate directory for each version of your application:

C:\Program Files (x86)\Company\YourApp\
    app.exe looks at available versions and launches the latest one.
    1.0.0.0\
    2.0.0.0\
        app.exe <- latest version

When performing an update, you can then simply create a new subdirectory (eg. 3.0.0.0) for the new version without disturbing any running instances of your app.

I had this idea too - have very small executable which will be resolving path to the latest version of the main app and starting it (launcher). This will make autoupdates really transparent for end users. In this case the main application will have to check for updates on its own, download the new version, unpack it to the new folder and update the latest version in windows registry or some kind of metadata file. Next time, when user will start application - launcher will pick up the new version for start. Main application will still be able to show notification that the new version is available and if user selected to install it - just start launcher and close itself. This looks very promising for me.

[matthew-dean]

Well, you'd still need to sign that file if you wanted to have proper signing, meaning even the launcher might need to be updated from time to time.

I'm still getting "Access Denied" on a particular Windows 10 installation (when attempting to rename C:\Program Files (x86)\My App to C:\Program Files (x86)\My App.bak) even when generating a new file with the update.syso file built in the same folder.

It works on one copy of Windows 10 on parallels, but fails on a different Windows 10 installation on a separate PC. Any ideas how to grant update.exe the right permissions from the start?

[oaleynik]

I'm not sure what can be wrong at the moment. I will try to test it at the moment and experiment with some other approaches for backups.

[tech4him1]

I had this idea too - have very small executable which will be resolving path to the latest version of the main app and starting it (launcher). This will make autoupdates really transparent for end users.

I haven't looked at it too much, but isn't that what Electron's auto-updater (Squirrel) does? If so, you might be able to look at/use some of their code.

[oaleynik]

@tech4him1 yes! This is exactly where I've got idea from. Would need to dive deeper in their internals to figure out how can we transition the same approach to NWJS.

[tech4him1]

Here is what I found for electron's updater files so far. Are you just wanting to build one for Windows first, or Mac as well?

Electron auto updater Docs:

• http://electron.atom.io/docs/api/auto-updater/#platform-notices

Electron auto updater API Files (used by app):

• https://github.com/electron/electron/blob/master/lib/browser/api/auto-updater.js
• https://github.com/electron/electron/tree/master/lib/browser/api/auto-updater
• https://github.com/electron/electron/blob/master/lib/browser/init.js#L67

Electron auto updater Native Files (used to build Update.exe?):

• https://github.com/electron/electron/blob/master/atom/browser/auto_updater.cc
• https://github.com/electron/electron/blob/master/atom/browser/auto_updater.h
• https://github.com/electron/electron/blob/master/atom/browser/auto_updater_mac.mm
• https://github.com/electron/electron/blob/master/atom/browser/api/atom_api_auto_updater.cc
• https://github.com/electron/electron/blob/master/atom/browser/api/atom_api_auto_updater.h

Electron auto updater updater (used to build Update.exe?):

• https://github.com/electron/electron/blob/master/script/update-external-binaries.py

[oaleynik]

@tech4him1 well, actually Mac first as I'm on Mac now :) Great list of resources, thanks! I will check it out!

[tech4him1]

OK, Mac would be good but you will have to work on it yourself, as I'm on Windows now :) The list I just made looking through the source, so I may have missed a few things, so please let me know if you find any more.

[oaleynik]

@tech4him1 nwjs/nw.js#5722 :)