electron-builder: Auto update doesn't work: `app-update.yml` is missing

Don’t close this issue. This is an automatic message by Fresh - a bot against stale bots.

This issue still exists on electron-builder@^22.6.0, tested on Windows 10 Pro (latest) and Linux Mint 19.3. I tried everything, including using the not-recommended setFeedURL, but nothing seems to work.

Every time user launches my app they see:

Unhandled Promise Rejection Error: ENOENT: no such file or directory, open '/opt/APP_NAME/resources/app-update.yml'

I checked the folder and the only file there is app.asar.

cc @develar

Always nothing new ?

Thank you @AndrewReisdorph this worked like a charm

Any updates? We are also facing the same

Any updates on this issue? This is still happening.

It would be nice if the file app-update.yml was generated independently of the targets.

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

I’ve encountered this issue while building on Debian 18.04. Christmas is coming, I can see where my holidays will go with this 😦

Hi, in case somebody has same issue (app-update.yml missing on Windows). Its generated only if one of the following targets is enabled: nsis or nsis-web. If you building only portable or zip + msi or any other combination of targets that doesn’t include nsis - app-update.yml won’t be generated as target is not “suitable” (source).

Also note, that this after pack handler that generates app-update.yml checks only build and platform publish config - it won’t generate config, if it set on target level on Windows/Mac.

And finally one more tip if you are building msi with auto-update: adding nsis target will trick builder to generate app-update.yml. But another important file that is required for updates elevate.exe is copied only as part of the following targets: nsis, nsis-web, portable, but not msi. Without this file when user will click install and restart application, it may crash with following error: Its not reproducing every time, you might successfully build few releases and then following erorr might happen because msi and other targets are build in parallel. So, on one build msi might be slower and nsis or portable target will copy elevate.exe into pack folder, next time nsis might be slower and msi will end up without elevate.exe. Links to source: all targets build in parallel, copyElevateHelper registration

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

Is this still relevant?

Very

I’m having a related problem. Our macOS and Windows builds work fine, but in the case of Linux it seems that app-image.yml is not being generated.

Here are some details about my use case. We don’t build the AppImage directly with electron-builder. Instead, we build to zip and then take that zip file and feed it into our build system, which builds it into a deb, an rpm and an AppImage. Updates are taken care of for the deb and rpm, but we’d like to use the update mechanism for the AppImage. However, as I said above, app-update.yml is not being generated for the zip file build. This means that the final AppImage does not contain app-update.yml, so it does not know how to find out if there is a newer version.

After doing some pretty significant digging into the electron-builder code, the only way I can see to work around this is for us to include an independent app-update.yml file in the project’s resources directory (i.e. one that is hard-coded and not generated from electron-builder.yml) and then parse it and pass it in the options to an AppImageUpdater. But this is not a good idea for a number of reasons.

As panther7 said above, it would be nice if app-update.yml could be generated independently of the targets.

This major bug is still present, three years later.

How is an end user affected by an application with this bug supposed to work around this? Is there some mystical incantation that can be put into the offending file to allow the application to actually run. I don’t want automatic updates. I just want the app to run. Waaail 😃

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

Hi ! I had this porblem before. But now it’s work and I don’t how I did. Just look my code if you need :

• My package.json : { "name": "kyo-panel-app", "productName": "kyo-panel-app", "version": "0.0.1", "description": "A minimal Electron application", "main": "main.js", "scripts": { "start": "electron .", "pack": "electron-builder --dir", "dist": "electron-builder", "publish": "electron-builder -w --publish always" }, "build": { "appId": "com.github.KyomiTeam.kyo-app-alpha", "publish": [ { "provider": "github", "owner": "KyomiTeam", "repo": "kyo-app-alpha" } ], "win": { "target": [ "nsis", "zip" ], "icon": "", "publish": { "provider": "github", "owner": "KyomiTeam", "repo": "kyo-app-alpha" } }, "nsis": { "installerIcon": "", "uninstallerIcon": "", "uninstallDisplayName": "Uninstaller - Kyo Panel App", "license": "./LICENSE.md", "oneClick": false, "allowToChangeInstallationDirectory": true, "perMachine": true } }, "author": "Kyomi", "devDependencies": { "electron": "^13.1.7", "electron-builder": "^22.11.7" }, "dependencies": { "electron-log": "^4.4.1", "electron-updater": "^4.3.9", "firebase": "^8.8.1", "firebase-admin": "^9.11.0", "fortnite-api-io": "^1.9.0", "update-electron-app": "^2.0.1" } }

Still having the issue for Windows:

“electron-builder”: “^22.11.1”,

That file (dev-app-update.yml) doesn’t exist anywhere on my machine. Why is it trying to find it??

My dist_electron directory:

Same issue for me on Linux only: Error: ENOENT: no such file or directory, open ‘/opt/app_name/resources/app-update.yml’

But it works well on Windows and Mac !

I was having the same issue, even though my build was working fine. I found that I have to have nsis in lowercase, it was previously uppercase. After doing so the app-update.yml and resources folder were properly built. I don’t know if this helps anyone but I thought I’d share.

"build": {
    "appId": "APP NAME HERE",
    "win": {
      "target": "nsis"
    },

Since there is no fix on this yet. I added "afterPack": "./afterPackHook.js", in the build part of package.json. afterPackHook.js file contains the code below. It generates the missing app-update.yml, however, after the new version is downloaded I get an error.

Error after new version is downloaded

New version 1.3.2 has been downloaded to /Users/amichael/Library/Application Support/Caches/demoapp-updater/pending/Demo App-1.3.2-mac.zip
/ requested
/1587329652828-8531.zip requested
/1587329652828-8531.zip requested by Squirrel.Mac, pipe /Users/amichael/Library/Application Support/Caches/demoapp-updater/pending/Demo App-1.3.2-mac.zip
Error: Error: ENOENT: no such file or directory, rename '/Users/amichael/Library/Application Support/Caches/demoapp-updater/pending/temp-Demo App-1.3.2-mac.zip' -> '/Users/amichael/Library/Application Support/Caches/demoapp-updater/pending/Demo App-1.3.2-mac.zip'

afterPackHook.js

'use strict'
const fs = require('fs')
const path = require('path')
const yaml = require('js-yaml')
exports.default = async context => {
    let data = {
        provider: 'spaces',
        name: 'demoapp',
        region: 'nyc3',
        path: '/test/'
    }
    switch (process.platform) {
        case "win32":
            data.updaterCacheDirName = 'demo-app-updater'
            data.publisherName = ['Company Name LLC']
            fs.writeFileSync(
                path.join(__dirname, 'dist','win-unpacked','resources','app-update.yml')
                , yaml.safeDump(data)
                , 'utf8'
            )
            break
        default: // unix
            data.updaterCacheDirName = 'demoapp-updater'
            fs.writeFileSync(
                path.join(__dirname, 'dist','mac','Demo App.app','Contents','Resources','app-update.yml')
                , yaml.safeDump(data)
                , 'utf8'
            )
            break
    }
    fs.writeFileSync(
        path.join(__dirname, 'dev-app-update.yml')
        , yaml.safeDump(data)
        , 'utf8'
    )
}

I ran into this problem when the publish key is defined at the appImage level and not at the linux level. In that case, the app-update.yml file is not generated.

Still relevant