Hi! I have no idea where i should report it, so i start here with the hope that somebody can help.
I have packaged my windows app with electron builder and i'm using Squirrel.Windows for auto-updates. I've put everything from the release to the FTP and set the URL properly. But now when I start the windows app its in an update loop. It downloads the 1.0.0 every time again.
Does someone has an idea how it happened?
859E5121E95B411FA2107DF3A59E3880D4E9EA0B myapp-1.0.0-ia32-full.nupkg 45302165
Main app index.js (i ommited unreleated code)
if (require("electron-squirrel-startup")) {
return;
}
app.on('ready', function() {
// create new browserwindow
// search for updates
const updateFeed = os == "darwin" ? "https://HOST/updates/latest" : "https://HOST/releases/win32";
const autoUpdater = require('auto-updater');
autoUpdater.on("update-downloaded", function() {
autoUpdater.quitAndInstall();
});
autoUpdater.setFeedURL(updateFeed + '?v=' + app.getVersion());
autoUpdater.checkForUpdates();
});
I am building the windows distribution with OSX (Vine) with the following command: build --platform win32 --arch ia32
You should show your code that handle auto-update...
Without that, it's pretty hard to help.
Sorry, i was currently editing my post, pressed publish accidently.
Side note: Don't call autoUpdater.quitAndInstall on "update-downloaded". You should quit only if user click "Ok, quit and install. But better solution is โ just show notification โ https://github.com/develar/onshape-desktop-shell/blob/master/src/AppUpdater.ts#L24
Please ensure that your updated app has greater version number.
@develar Thanks, yes i've not implemented it correctly yet, just want to get it running first :/ And thanks for the code snippet!
[26/Apr/2016:08:50:33 +0200] "GET /downloader/releases/win32/RELEASES?v=1.0.0&id=youtv&localVersion=1.0.0&arch=amd64 HTTP/1.1" 200 91
[26/Apr/2016:08:50:49 +0200] "GET /downloader/releases/win32/youtv-downloader-1.0.0-ia32-full.nupkg HTTP/1.1" 200 45302165
[26/Apr/2016:08:50:49 +0200] "GET /downloader/releases/win32/RELEASES?v=1.0.0&id=youtv&localVersion=1.0.0&arch=amd64 HTTP/1.1" 200 91
[26/Apr/2016:08:51:27 +0200] "GET /downloader/releases/win32/youtv-downloader-1.0.0-ia32-full.nupkg HTTP/1.1" 200 19496705
Please see https://github.com/electron/electron/issues/5057
Do you code sign your app?
Thanks for the link.
No, im not code signing the windows app at the moment. Could it prevent the issue?
Could it prevent the issue?
No, it can be a reason of issue.
Code signing didn't help.
What's happening:
I found the issue. I think its a bug in Squirrel.Windows.
I have always uploaded the ia32 version and not the 64bit version. I installed the 32 bit version on a 64bit PC and got into this loop issue. After uploading the 64bit RELEASES + nupkg it worked fine.
@philipgiuliani It is your issue due to lack of documentation. Please see https://github.com/electron-userland/electron-builder/issues/190#issuecomment-191885842 Your update server must serve RELEASES-ia32 as RELEASES on 32-bit update request.
Reopened โ must be documented.
When i generated 32 bit version it generates a RELEASES + RELEASES-ia32. I uploaded both and the content seemed the same. The app fetched the RELEASES file (from logs) and downloaded the app-ia32.nupkg. But looping. So the file was actually present. Thanks for your help.
The app fetched the RELEASES file
It is an issue in all known update servers. You must send RELEASES-ia32 if RELEASES requested for 32-bit version. See, for example, issue https://github.com/GitbookIO/nuts/issues/32 โ nuts server just doesn't support 32-bit releases.
I suggest to distribute only 64-bit versions (forget 32-bit). Or you must fix your update server to support both 32 and 64 bit releases.
But looping.
I see &arch=amd64 in your URL. Are your sure that proper file is returned (i.e. 64-bit version)?
And please, as an easy solution โ "I suggest to distribute only 64-bit versions (forget 32-bit)." :)
I uploaded both and the content seemed the same
If you build only 32-bit, RELEASES file is generated as well and identical to RELEASES-ia32. Yes โ it is a bug โ we must not generate RELEASES file in this case. I will check.
Yes we're now only distributing 64-bit versions. My update server has currently no logic (just for Squirrel.Mac) because they said Squirrel.Windows doesn't need that. Feel free to close when its fixed :) I'm happy with 64 bit.
I'm happy with 64 bit.
Good, because real fix is not possible on our side. RELEASES file cannot contain versions for several archs, so, it is update server responsibility to handle this issue. And reality is โ no one update server implements it correctly because... damn windows! forget ia32 and use only 64-bit as OS X does for several years.
On other hand if you distribute only ia32, we should still generate RELEASES file. So, it will be not changed.
It took me about 5 minutes to get OS X updates working... For Windows i spent a day to find out that it is because i only uploaded the x86 version... Yes i think its ok to generate it because its required.
I ran into this issue on a project and found a solution. Due to certain restrictions, our application is only available as a 32-bit program, so we had to find a fix for this.
During the build process, electron-builder would output the following files:
app-0.1.0-ia32-full.nupkg
AppSetup-0.1.0-ia32.exe
RELEASES
RELEASES-ia32
Our fix was to:
RELEASES-ia32-ia32 strings from the filenamesBelow is our build script that does this:
builder.build(opts)
.then(() => {
const dir = jetpack.cwd('dist', 'win');
// This is a fix for Squirrel's infinite update loop.
return dir.removeAsync('RELEASES-ia32')
.then(() => {
return Promise.each(dir.listAsync(), (filename) => {
if (filename.indexOf('-ia32') !== -1) {
const newFilename = filename.replace('-ia32', '');
return dir.renameAsync(filename, newFilename);
}
});
})
.then(() => {
return dir.readAsync('RELEASES');
})
.then((txt) => {
txt = txt.replace('-ia32', '');
return dir.writeAsync('RELEASES', txt);
});
})
.catch((err) => {
console.log(err);
process.exit(1);
});
@bontibon I will revert https://github.com/electron-userland/electron-builder/issues/190#issuecomment-218956898 if @mcaoun will confirm that fix doesn't work in any case.
cc @demetris-manikas
So
If @mcaoun will not say that "don't revert, it works for me!", I will publish fix in the 3.x version, not major 4.
@bontibon Enjoy. 3.22.0 will not modify RELEASES for ia32 anymore.
How can you just break all existing build processes? There are many developers depending on these projects. Yes, we would love to live in a perfect world where we do not care about customers that do not upgrade.
@friksa What do you mean?
Our build process was building win32 versions of electron happily. After these changes, it does not.
@friksa Please specify error, or what's wrong?
Got to the bottom of this and it turns out to be easily solvable in the morning. The build process always yielded a folder named "win". Now it is "win-ia32". This caused the build process to break. Adjusting the build process to use the new folder name resolves the issue. Thanks!
@friksa Sorry for that. Could you please specify why "the build process to break"? Do you publish manually instead of github publisher (or creating issue "support my product_name (amazon s3?) to publish!!!")?
We build it with
npm run clean:win && ./node_modules/.bin/build --platform win32 --arch ia32 && node tasks/sign
Then we scp the files to our server and use a home-grown Java server to serve updates.
Since the files were not found in the expected place, the build process reported a broken build.
node tasks/sign
BTW, code sign is supported (and it is not possible for you to sign correctly outside of build process).
@friksa Thanks for explanation.
I wrote a blog post about building and deploying app, and it supports both 32 and 64 versions of Win:
http://electron.rocks/building-and-deploying-application/
Hope it helps, best,
Vjeko
@Vj3k0 Thanks a lot for your articles. Please see and comment if possible https://github.com/electron-userland/electron-builder/issues/413
@develar for future reference, in what version was this issue introduced and in what issue is it fixed (or has it even been fixed)? Thanks!
@ccnokes It not our bug, it is Squirrel.windows&nuget design mistake and as unpreventable result โ user configuration error. There is no fix โ we just revert our feature, because we don't want to fix broken windows. Please see https://github.com/electron-userland/electron-builder/issues/439
Hi,
I have both a 32-bit and 64-bit release of my app and the auto-updater work well with both arch.
When the app starts, I make a request on my server with the following parameters: current app version, platform, arch to check if an update is available. If the current version is already up to date nothing happened... otherwise I call autoUpdater.setFeedURL(feedUrl); with the feedUrl returned by the server (that depends of the version, platform and arch).
I think I just met the same looping issue, I reported details to electron project and here is the link.
https://github.com/electron/electron/issues/8040
Squirrel.Windows is deprecated by electron-builder โ consider to use nsis target.
@develar can you still use the electron autoupdater api with nsis? I thought it relied on squirrel.windows.
Nevermind, I see #529 now.
This bug has been solved in Squirrel?
Most helpful comment
It took me about 5 minutes to get OS X updates working... For Windows i spent a day to find out that it is because i only uploaded the x86 version... Yes i think its ok to generate it because its required.