Abstract

Reading this article requires a basic knowledge of Electron and Node. This article only focuses on the automatic update mechanism of Electron.

At present, the feasible scheme in this paper is only applicable in Windows environment, and it is urgent to study the scheme in Mac and Linux environment.

Several schemes are studied and tested. The scheme is described as follows: Update Electron application with built-in Squirrel framework and autoUpdater module of Electron.

If you are not familiar with Electron, please see my humble article “Electron Field”.

keywords

Electron Nsis Squirrel. Windows Update. Exe

The body of the

This article was first published on the public account “Full stack big guy’s Cultivation road”, welcome to follow.

The background,

Figure 1 Electron

Like many frameworks for desktop applications (including the older vc6.0, as well as c#, asp.net, QT, Java, Delphi, C++BUILDE, to name a few), Electron had to be packaged and distributed to every user while developing the XXX project.

Second, existing problems

When we add new features to the application and submit new code, of course, we expect it to be automatically updated on the user’s computer. But the original operation looks like this:

  1. After submitting the code, useWebpackPackage up the obfuscation code and reuse itElectronPackaging tools package compressed code to generate executable files;
  2. Find the package generatedexeAnd other execution files;
  3. The generatedexeSend to the user for the user to reinstall.

If you’re a user, it’s annoying. It’s annoying not only for users, but also for developers. Is there a way to distribute updates and automatically update applications on users’ computers? The answer must be yes.

Three, automatic update scheme

Let’s take a look at the Electron website for help. The Electron team is keeping Update.electronjs.org, a free open source web service that Electron applications can use to update themselves. This service is designed for those Electron applications that meet the following criteria:

  1. The application runs onmacOSorWindows;
  2. The application is publicGitHubWarehouse;
  3. The compiled version is available atGitHub Releases;
  4. The compiled version is signed by the code.

The easiest way to use this service is to install update-electron-app, a pre-configured Node.js module to use update.electronjs.org.

However, the XXX project is a company private project, and according to the company’s network security rules, the application cannot be deployed on GitHub and released publicly in GitHub Releases, so you need to run your own update server.

That’s okay. With that in mind, the Electron team has come up with some update servers that can be deployed privately. The update server in the scenario has the following:

  1. HazelUpdate servers for private or open source applications are available on theNowFree deployment on. It is fromGitHub ReleasesPull the update file and useGitHub CDNPowerful performance;
  2. Nuts— Also usedGitHub Releases, but caches application updates on disk and supports private repositories;
  3. Electron-release-server— Provide a dashboard for handling releases that does not require aGitHubPost;
  4. Nucleus– aAtlassianMaintenance of theElectronA full update server for the application. Supports multiple applications and channels, using static file storage to reduce server costs.

The official servers have been analyzed, and Hazel and Nuts rely on GitHub releases to pull updated files, so these two don’t apply. Both Electron release-server and Nucleus have been tested to work. Docker technology is used for deployment. The update server address obtained after deployment needs to be used.

Once the update server is deployed, you can import the required code modules. The following code is in the packaged application only, not in development.

I distinguish between development and production by app.ispackaged attributes:

if (app.isPackaged) {
  require('./update')
  getAutoUpdateDep()
}
Copy the code

Import dependencies:

const { app, autoUpdater, dialog } = require('electron')
Copy the code

Next, build the update server URL and notify autoUpdater:

const server = 'Server address'
const url = `${server}/update/${process.platform}/ ${app.getVersion()}`

autoUpdater.setFeedURL({ url })
Copy the code

As a final step, check for updates. The following example checks once an hour:

setInterval(() = > {
  autoUpdater.checkForUpdates()
}, 3600000)
Copy the code

Once the application is packaged, it will receive every update I post to the server.

Now that you have configured the basic update mechanism for your application, you need to ensure that users are notified of updates. This can be done using autoUpdater API Events:

autoUpdater.on('update-downloaded'.(event, releaseNotes, releaseName) = > {
  const dialogOpts = {
    type: 'info'.buttons: ['restart'.'later'].title: 'Apply updates'.message: process.platform === 'win32' ? releaseNotes : releaseName,
    detail: 'The application has been updated, please restart'
  }

  dialog.showMessageBox(dialogOpts).then((returnValue) = >
    if(returnValue.response === 0) autoUpdater.quitAnd()
  })
})
Copy the code

Currently, the detailed steps of the XXX project update, which UpdateManager performs each time the application is executed, are as follows:

  1. Check for updates. Download the distribution locationRELEASESFile and work with localRELEASESFiles are compared to check for updates;
  2. Download and verify the update package. If there’s a new version,UpdateManagerThe decision is to downloaddeltasOr the latest full package (by calculating which one requires fewer downloads) to update to the current version. These packages andRELEASESIn the fileSHA1To make comparisons for verification;
  3. fromDeltasBuild the complete package. If you’ve already downloaded itdeltaThe package will then be downloaded from the previous complete packagedeltaFile to create a new complete package;
  4. Install the new version. Extract the current version from the full packagexxxProject, and based on the version number (e.gApp - 1.0.1) Put it in a new one%LocalAppData%\xxxProject installation directory;
  5. Shortcuts are not updated. newxxxThe project installation location has been replacedxxxProject location, so the shortcut address is still old;
  6. Previous version cleanup. After the installation is complete, usereplace.bat 将 xxxThe new version of the project replaces the old version. (Such as update toApp - 1.0.5Later,App - 1.0.4Delete all before).
  7. Currently, there is no built-in support for rolling back to previous versions.

See Section 5 for detailed codes for some of these steps.

Here are two possible solutions for updating servers and the packaged update mechanisms they rely on.

(1) Electric-Builder with electric-release-Server

For the introduction of Electron Builder, the website is quite detailed, a complete solution for packaging and setting up “Auto Update” ready to distribute the Electron application out of the box. Here are two ways to configure Windows in the Electron Builder, Squirrel. Windows and Nsis, but I won’t mention the rest.

  1. Squirrel.windowsAutomatic update, which is installed under the local user account by default%LocalAppData%Under (e.g.,xxxThe project will be installed inC: \ Users \ \ AppData \ Local \ XXX UsersFolder), and is generated automaticallypackagesThe folder andUpdate.exeThe program.packagesContains version informationRELEASESFile. If there’s an updated version of hisnupkgIt will also be downloaded into it. During this time, automatically updated logs are storedSquirrelSetup.logIn the.
  2. NsisAutomatic update mode andSquirrel.windowsSimilar. However, this does not occur after installationpackagesThe folder andUpdate.exeThe program. After the installation is enabled, you can select installation steps such as installation directory for installation. The granularity of installation becomes more detailed.

When creating a project, scaffolding can choose whether to integrate the Electron builder, XXX project configuration parameters are as follows:

"build": {
    "win": {
      "target": [
        "nsis"."zip"."squirrel"]."icon": "XXX project. Ico"."publish": [{"provider": "generic"."url": ""}},"squirrelWindows": {
      "iconUrl": "https://path/to/valid/image.png"
    },
    "linux": {
      "icon": "build/icons"
    },
    "nsis": {
      "oneClick": false."allowElevation": true."allowToChangeInstallationDirectory": true."installerIcon": ". / XXX project. Ico"."uninstallerIcon": ". / XXX project. Ico"."installerHeaderIcon": ". / XXX project. Ico"."createDesktopShortcut": true."createStartMenuShortcut": true."perMachine": false."unicode": true."deleteAppDataOnUninstall": false
    },
    "extends": null
  }
Copy the code

The directory generated by the Electron builder package is as follows:

Exe ├─ Slow slow slow slow slow Slow Slow Slow Slow Slow Slow Slow Slow Slow Slow Slow Slow ├ ─ XXX - 0.0.1 - full. Nupkg ├ ─ XXX - hundreds - full. Nupkg ├ ─ XXX - 0.0.3 - full. Nupkg └ ─ win - unpacked ├ ─ libs... ├─ ├─resources │ ├─ ├─ unpacked │ ├─ ├─ unpacked │ ├─ ├─ ├... ├─ bass Exercises, └─ bass Exercises, ├─ bass Exercises, ├─ bass Exercises, ├─ bass Exercises, ├─ bass Exercises, ├─ bass Exercises Exe. Blockmap ├─ Anti-Flag school - XXX 0.0.1-win.zip ├─ XXX 0.0.2-win.zip ├ ─ XXX - 0.0.3 - win. ZipCopy the code
  1. build: Folder generated by packaging;
  2. Nupkg: is a.nupkgExtended singleZIPFile, this extension contains compiled code (Dll), other files related to the code, and descriptive listings (including package version numbers, etc.);
  3. squirrel-Windows: the product of the packaging method, includingexe 和 nupkg. The difference innsisPackaged upexe;
  4. win-unpacked: source code.

See section 4 of two ways to pack for details.

The Electron-release-server provides a background Squirrel. Windows automatic update.

The Electron release-server will provide the NuGet package on the following interface:

  1. Download.myapp.com/update/win3…
  2. Download.myapp.com/update/win6…
  3. Download.myapp.com/update/win3…
  4. Download.myapp.com/update/win6…
  5. Download.myapp.com/update/flav…
  6. Download.myapp.com/update/flav…
  7. Download.myapp.com/update/flav…
  8. Download.myapp.com/update/flav…

If no channel is specified, then stable will be used. If flavor is not specified, default will be used. If Win64 is available but only Win32 assets are available, it will be used. Note: If desired, use Windows_32 instead of Win32 and Windows_64 instead of Win64. As long as the management Update. Exe or Squirrel. Windows to use http://download.myapp.com/update/win32/:version/:channel as a feed URL without any query. For example, the XXX project only needs to create a new version, upload.nupkg and setup.exe.

Electron forge with nucleus

The Nucleus update server is similar to the above, the electron-Forge package is similar to the electron-Builder, it is only known that it can be updated through Squirrel mode, but whether it can be updated using Nsis installation configuration is unknown.

During this period, the auto-updating schemes of Electron- Packager, Electron- Winstaller and Electron-updater are also investigated, and their packaging principles are similar with minor differences.

The first two use Electron native Autoupdate to package dist into applications in different ways. Packager is a command line tool and node.js library. It packs the Electron application source-based, renamed Electron executable, and supporting files into a distribution-ready folder; Winstaller is an NPM module for building the Electron application into a Windows installer with Squirrel. The last is to encapsulate the native Autoupdate mechanism.

Four, two ways to pack

If we’re going to talk about automatic updates, we have to talk about Electron packing.

Squirrel. Windows

Squirrel. Window mascot

It is a set of tools and a library that fully manages the installation and updating of desktop Windows applications written in any other language.

Windows apps should be installed and updated as quickly and easily as Google Chrome. From an application developer’s point of view, it should be simple to create an installer for your application and release updates without going through tedious steps. Windows can take care of some of these tedious steps.

configuration
  1. For existing.NETThe application integration installer should be easy;
  2. The clientAPIShould be able to check for updates and receive one (preferablyHTMLFormat) update log;
  3. Developers should control custom actions and events during installation and updates;
  4. Unload gives the application a chance to clean up (for example, you can run a piece of code at unload time).
packaging
  1. For existing applications, generating the installer should be as simple as forClickOnceThe same;
  2. Creating an update for my application should be a very simple process that is easy to automate;
  3. Packaging will support incremental files to reduce the size of update packages.
distribution
  1. Hosting an update server should be very simple, and should be able to use simpleHTTPTo accomplish (e.g.,xxxThe project is hostedelectron-release-server);
  2. Support multiple channels for release.
The installation
  1. Install to a local user account (for example, in%LocalAppData%Below);
  2. No restart.
update
  1. Updates should be applied while the application is running;
  2. At no time should a user be forced to stop what he or she is doing;
  3. No restart.

Figure 3 Squirrel. Windows installed by default

(2) Nsis method

Nullsoft Scriptable Install System Nullsoft Scriptable Install System is an open source Windows installer. It provides installation, uninstallation, system Settings, file decompression and other functions. As its name suggests, NSIS describes the behavior and logic of the installer through its scripting language. The scripting language of NSIS has a similar structure and syntax to normal programming languages, but it is designed for applications such as installers.

The NSIS key contains a set of options that indicate how the Electron builder builds the NSIS target. These options also work with Web installers, using top-level nsisWeb keys.

The configuration of nSIS refers to the configuration of the installation process. In fact, it is very important. If nSIS is not configured, the application will be automatically installed on disk C. There is no room for users to choose, so it is certainly not possible. It then occurred to me that it would be a good idea not to combine NSIS and Squirrel. Windows to produce XXX projects, using both Squirrel. Windows update mechanism and nSIS custom installation.

The nSIS configuration is done in the nSIS option in build. Here are some nSIS configurations:

"nsis": {
  "oneClick": false.// Whether to install with one click
  "allowElevation": true.// Allow request promotion. If false, the user must restart setup with the promoted permissions.
  "allowToChangeInstallationDirectory": true.// Allows you to change the installation directory
  "installerIcon": "./build/icons/aaa.ico".// Install icon
  "uninstallerIcon": "./build/icons/bbb.ico".// Uninstall the icon
  "installerHeaderIcon": "./build/icons/aaa.ico".// Install header icon
  "createDesktopShortcut": true.// Create a desktop icon
  "createStartMenuShortcut": true.// Create start menu icon
  "shortcutName": "xxxx".// Icon name
  "include": "build/script/installer.nsh".// The included custom NSIS script is quite useful for building a strict installation process.
}
Copy the code

Which one should I choose between include and script? In the personalized installation process requirements are not complicated, just need to modify the installation location, uninstall prompts and other simple operations recommended to use include configuration, if you need cool installation process, it is recommended to use script to fully customize. The XXX project uploaded to the server is the setup.exe packaged by NSIS.

Figure 4 nSIS custom installation

Similarities between Nsis and Squirrel. Windows:

  1. The previous version of the application still exists after the update. Older versions of the application persist.
  2. Package – Package the application files and prepare them for release.
  3. Installation – The process of initially installing an application.

Differences:

  1. NsisThere are more granular installation.
  2. NsisUnable to generatepackagesThe folder andUpdate.exeThe program.
  3. Squirrel.windowsIt can only be installed in a local user account.
  4. Squirrel.windowsIntegration –Squirrel UpdateManagerIntegrate into your application. Distribution – Provides installation and update files to users. Update – The process of updating an existing installation.

summary

Series 1 provides an in-depth look at how this works from the auto-update scenario, as well as two packaging options.

In the next series, let’s look at some of the problems with automatic update development.

reference

Updating the application

Finally, I hope you must point to like three times.

You can read my other posts at the blog address