May i ask why you dropped NSIS completely?
Dont get me wrong squirrel is nice but it can't do it all. And most of my clients don't really like/understand those installer which give them no choice (installation directory, ...).
Also squirrel does not seem to support installation of 3rdarpties (like boujour SDK, or any other needed drivers)
I could go and not use electron-builder at all but that's not what i want.
I could fork electron builder and bring it back from where you dropped it, but again not really good for the community.
Could we talk about it? about bringing it back?
Thanks
Also squirrel does not seem to support installation of 3rdarpties
Your app can install anything after run (on first launch / on squirrel event).
Could we talk about it? about bringing it back?
I cannot say that I am happy to use / maintain Squirrel.Windows.
And I understand that it is not developer responsibility to teach users. Windows is Windows.
Personally, as OS X user, I don't like installers. pkg is very rare on OS X (and often indicator that this developer/company is bad / don't think about users"). And I think Squirrel.Windows should be preferred way to distribute, and don't forget about auto-update.
In short: you can expect NSIS and 7z sfx targets next week. If you think that there is a better installer framework than NSIS, please recommend it.
@develar First thanks a lot for taking the time to answer. And i am really happy to to see NSIS coming back.
As an OSX user i really don't like installers either, but Windows and OSX are totally different in the way you integrate 3rdParties. I thought about running the installer on first run but i don't really like it. It means i either have to package the 3rdparty installer in my app package or get it from the web. Not really fond of it. I like the installer becasue that's the way to do it on windows... Just like deb is the way to do it on linux.
Plus install location is kind of a big issue on windows. Especially in companies where there are permission issues. And there is also "permission actions". Which is mostly why you have pkg on OSX.
I think that's why big projects decide to stay with NSIS or else like VSCode for example.
I see squirrel as the best solution for portable install with updater like it is on OSX.
By the way about the update system. You can use sparkle or winsparkle, which i think i am gonna go for.
I have already looked (a few years ago, just coming back to desktop dev) at other solutions. Nothing much better right now i think.
Thanks again @develar
By the way about the update system. You can use sparkle or winsparkle, which i think i am gonna go for.
NSIS is enough โ just download and run installer silent โ https://github.com/codeskyblue/electron-inno-auto-update (this example for inno setup, but the same for NSIS). And you can use standard electron auto-update API โ no vendor lock.
NSIS seems to outperform Squirrel.Windows:
It will require work on our side, though, but it seems it is better to invest into NSIS, than fix "broken" (sorry, sorry) Squirrel.Windows again, again and again (I am tired).
@develar i think that answers my question https://github.com/Microsoft/vscode/issues/7227 !
:+1: for bringing back NSIS. Although @paulcbetts work on Squirrel is awesome, it just doesn't cut it for me. Don't get me wrong, maybe Squirrel will become "must-have" in the future, but for now it just doesn't suffice.
@JimiC Yes, NSIS outperforms Squirrel.Windows in all aspects โ yes, it requires the same work to make it excellent as fixing Squirrel.Windows (but result will be much more stable and robust, instead of maintaining our own fork of Squirrel.Windows). Maybe we even make NSIS by default.
Electron will always be using Squirrel as its installer for the foreseeable future. If electron-builder wants to integrate NSIS or another installation framework instead they're of course entirely in their right to do so.
@paulcbetts Current plan just add additional target.
Electron will always be using Squirrel as its installer for the foreseeable future
If I understand correctly, it is only bundled auto-update API implementation, right?
If I understand correctly, it is only bundled auto-update API implementation, right?
Correct
In any case electron-builder choses Squirrel - it loses a piece of pie.
We don't choose anything. We are orchestration tool. I like Squirrel.Windows as user and for now it will be default windows target. The same as in case of Linux โ by default deb, but you can build rpm, packman and other 5+ formats if you want.
I dont need VS and NUGET in my work.
Squirrel.Windows doesn't require you to use it. .net is not a problem in the modern Windows versions.
Inno Setup seems better than NSIS for some reasons.
Please describe such reasons.
My .02 cents here. From my POV if I had build electron-builder I would had provided choices when it comes to windows installer builders, just like it does now with Linux. With a simple 'win' specific option (i.e packager ?) with available values either 'squirrel', 'nsis' or 'inno' (default could be 'squirrel'). But I'm not the builder.
@englishextra I personally tried to build Squirrel.Windows as I'm mainly a .NET developer and VS is my choice of IDE. Got stuck a little bit figuring out that I had to add the ILRepack nuget package (not inluded in the project), Windows SDK and C++ tools, but after that I had no issues. But not everyone knows its ways around Windows Software development, so I give you that.
@JimiC offtopic: electron-builder fork of Squirrel.Windows builds on CI server โ see https://github.com/develar/Squirrel.Windows/blob/build/appveyor.yml To avoid any issues on development machine.
I updated via npm electron-builder and launched the build process as usual, and it failed. That's why I started to install Squirrel.Windows.
In this case just report issue here before digging.
@englishextra Sorry, I meant to edit my comment but deleted it (git noob). What failed in your build process? I know this is probably not the place to ask about that but myself and other devs on my team have been using electron-builder and its been working magic. Squirrel.Windows is indeed a pain to deal with, but thankfully @develar dealt with it. I don't see how it would fail or give you a hard time unless you had a weird configuration, but this blog by @Vj3k0 is excellent, and should smoouth out the process. I'm open to helping you set up electron-builder or answering questions you have if you write up an issue!
You see I have no tools to debug where electron-builder gets stuck - since cmd simply goes down throwing no error.
Just _report_ issue. No report โ no help or fix. _All_ tools has debug output if set DEBUG env.
@englishextra I believe iconUrl is mandatory for .build.win. In my case I have only that in the options and win installer builds just fine. But then again I build win installer on a Windows machine.
@englishextra remove everything but the iconUrl and try again. By the way are you building on Windows or another env?
Aha! What's the resolution of the favicon.ico? ICO must be mininum 256px for Windows. (see https://github.com/electron-userland/electron-builder/issues/467)
@englishextra what's version doing in there? Take it out.
If you meant to specify the electron version, do it in build, not in win, and do so like this:
"build": {
"electronVersion": "1.2.1",
"win": { ... }
}
@englishextra Didn't said to remove iconUrl but remove everything else BUT the iconUrl. Also read my comment again (about the ICO size).
@englishextra I can speak russian. Feel free to contact me. And please let's stop off topic here ;)
@englishextra
I can speak russian. Feel free to contact me.
He meant that if you're stuck somewhere, and there's a language barrier for you _specifically_, he can help you in russian if you do need it. He was just trying to be nice.
As @JimiC said:
With a simple 'win' specific option (i.e packager ?) with available values either 'squirrel', 'nsis' or 'inno' (default could be 'squirrel').
is the solution to this issue. But squirrel should remain the default. It outperforms NSIS in ease-of-installation (nothing to click...) and that's what matters most.
@kunkinkan Our Nsis target with default options will produce one-click installer without admin rights requirement as Squirrel does. But size will be 50% less, installer will have true progress bar, shortcuts and file associations in the declarative cross-platform way (so, installation will be a little bit faster). And will be ability to pack ia32 and x64 editions in one installer.
But of course nsis will be not default target for now.
NSIS is amazing. Yes, it is far from ideal (for developers, not for users), but our NSIS one-click installer:
Instead of fixing Squirrel.Windows (net code), you can easily modify text file and do what your want. It is amazing. It is implemented and will be pushed soon.
@farfromrefug Thanks! I will not waste my time to fix Squirrel.Windows anymore. NSIS will be default target once it will be ready for production use.
It is one-click per-user installer as Squirrel.Windows, but options
export interface NsisOptions {
/*
Mark "all users" (per-machine) as default. Not recommended. Defaults to `false`.
*/
readonly perMachine?: boolean | null
/*
Allow requesting for elevation. If false, user will have to restart installer with elevated permissions. Defaults to `true`.
*/
readonly allowElevation?: boolean | null
readonly guid?: string | null
/*
One-click installation. Defaults to `true`.
*/
readonly oneClick?: boolean | null
}
allows you to configure it or allow user to choose.
Source code is easy to customise (i.e. you don't need to copy the full script just to modify several lines), so, you do what you want (but keep in mind โ it is better for all to open PR and add functionality using flags).
Does this install in the same location as with squirrel.windows?
@kunkinkan Not exactly, because we must install not to LocalAppData/AppName, but to LocalAppData/Programs/AppName according to Win7+ standard (Win7+ has a per-user programfiles known folder). You can set nsis.perMachine to true to change default.
When will NSIS be available? I'll be releasing an app pretty soon, don't want to have 2 install locations. (unless there's some kind of squirrel removal done by NSIS ;-))
How will updates work without squirrel events?
@kunkinkan I suppose you have to implement a way to let your program know that there is an update available (poll on a known url to scan for changes ?) and then download the new version and let NSIS silently update the old installation.
@JimiC so it's not going to work with electron.autoUpdater ?
The autoUpdater module provides an interface for the Squirrel framework.
electron.autoUpdater
electron.autoUpdater API will be supported in the same way as Squirrel.Windows and bundled (i.e. no external dependency in your app). In your app you will change the only line โ URL of updates.
When will NSIS be available?
As we are an opensource project, it depends on you ;) I think #495 will be landed today. But autoupdate will be implemented later.
unless there's some kind of squirrel removal done by NSIS ;-)
Because it is NSIS, it is very easy to do anything you want. Probably it will be implemented as well (PR is welcome).
@develar great work on your part. Thanks a lot!
Most helpful comment
NSIS seems to outperform Squirrel.Windows:
It will require work on our side, though, but it seems it is better to invest into NSIS, than fix "broken" (sorry, sorry) Squirrel.Windows again, again and again (I am tired).