electron-builder: NSIS Installer stuck at "Installing, please wait..."
- electron-builder Version: 21.0.15
- Target: win10 nsis
Package.json:
"build": {
"asar": false,
"win": {
"target": "nsis"
},
"nsis": {
"runAfterFinish": false,
"artifactName": "${productName}-${version}-instalador.${ext}",
"oneClick": true
}
}
installer.nsh:
!macro preInit
SetRegView 64
WriteRegExpandStr HKLM "${INSTALL_REGISTRY_KEY}" InstallLocation "C:\${COMPANY_NAME}\${PRODUCT_NAME}"
WriteRegExpandStr HKCU "${INSTALL_REGISTRY_KEY}" InstallLocation "C:\${COMPANY_NAME}\${PRODUCT_NAME}"
SetRegView 32
WriteRegExpandStr HKLM "${INSTALL_REGISTRY_KEY}" InstallLocation "C:\${COMPANY_NAME}\${PRODUCT_NAME}"
WriteRegExpandStr HKCU "${INSTALL_REGISTRY_KEY}" InstallLocation "C:\${COMPANY_NAME}\${PRODUCT_NAME}"
!macroend
Installer gets successfully built but when executed gets stuck at “Installing, please wait…” forever
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 33
- Comments: 52 (10 by maintainers)
Commits related to this issue
- Update electron-builder to 22.9.1. A user reported that if they manually removed the Project Clippi folder instead of uninstalling properly, they can no longer install or uninstall the application. S... — committed to vinceau/project-clippi by vinceau 3 years ago
- Fix broken uninstall (#118) A user reported that if they manually removed the Project Clippi folder instead of uninstalling properly, they can no longer install or uninstall the application. Suppos... — committed to vinceau/project-clippi by vinceau 3 years ago
@develar hey there, any official plans/workarounds for this?
I never saw this issue with
20.39.x- I’m pulling my hair out over this bug on literally day 2 after upgrading to the latestelectron-builder. If this happened to a user, I can be pretty sure they’re never getting this fixed, giving up, and lost to us forever as a user.THIS IS A CRITICAL BUG
Any updates on this? This is reported very frequently from our users and we dislike telling them to manually remove a registry key…
If bugs as serious as this still exist after a year, this repository should be marked as unmaintained. Just saying.
We have found that the issue was because of old registry key at
Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall, which had the same guid, but without curly braces. So we had{308cc20e-7a56-5705-91f7-e9a0f443a5cd}as correct one, and308cc20e-7a56-5705-91f7-e9a0f443a5cdas incorrect one. Deleting308cc20e-7a56-5705-91f7-e9a0f443a5cdsolved the issue.This is worth noting that we didn’t change the appId. it seems like the installer bug in some old version? We currently use electron-builder v22.1.0
@develar This is a rather critical bug. Users who delete the app folder manually or with some weird tools cannot reinstall the app. Is this fixable with a custom NSIS script?
For future googlers, to addendum my previous comment: I created an
installer.nshfile in my build directory, and filled it with the contents of @o2genum 's post:22.9.1marked as release.My workarounds for this issue:
@Slapbox That’s exactly what happened to some of our users. Auto updater fails and then application becomes untouchable be either installer or uninstaller.
This is the problematic commit, which caused breaking change: https://github.com/electron-userland/electron-builder/commit/7518aee8e1abe0516071b350748e84dc47e35cf7
I suggest developers to handle this situation in code so that users of
electron-builderwon’t have to send .reg files to their users 👍Just ran into this, kind of surprised the installer is completely stuck on this…
For whoever run into this situation, use CCleaner to manually remove the entry from Windows Program list. Then re-run the installer.
For reference, see this page
Generally the only time I see this behavior is when an existing install has been deleted rather then explicitly uninstalled via Add Remove Programs or the uninstaller itself.
Hit the bug yet again.
Google
electron builder "critical bug"and this is the first result.Could we get any comment on this very serious problem?
Some of my users have been complaining about this issue, though I tried to explain how to manually delete the registry some of them don’t feel comfortable in doing it themselves.
We need a fix for this bug
OMG. This has worked. I don’t know what I’ve actually done.
Yes, the existing install was indeed deleted instead of being uninstalled properly, but the installer should be able to handle this fairly common situation and install it anyway or at least show some kind of error
We just ran into this issue and after spending 20 minutes walking through it with a user (using the solution suggested by @gomorizsolt and @stilettk) and it worked.
Because the registry key is just a bunch of gibberish, it’s impossible for us to even give people reasonable instructions to handle this themselves.
Echoing what’s been said: even an error message would be far better than the current behavior.
IMO this is pretty critical indeed. Tried to install an electron-based application, but our company policy didn’t allow the installation at first.
After it being allowed and me trying to install it again it got stuck due to this issue
This is quite confusing for end users, is it able to force re-install new versions?
Can confirm that this still happens for me as well 😦
This still happens for our project as well. @develar
Yea, to me its a pretty critical issue and should be higher prioritized. Would give it a shot myself if I was comfortable with the codebase.
It’s remarkable to me that on this nearly year old issue, there’s a single response from a contributor, and it’s to say that they’re having the issue also…
We’re having this problem too and it’s very frustrating
We’ve also encountered with the exact same situation. After removing the app’s folder manually, the installer kept hanging around nearly half of the process.
Even though it’s supposed to be the expected behavior, it’s not the case here. We could eliminate the issue by removing the so-called
UninstallStringregistry from the system, for which you should:Registry EditorEdit/Searchand search for your application’s nameFile/ExportIt’s quite cryptic why it actually works this way and I’m also not familiar with this whole registry system at all, but hopefully someone will find it useful until there’s no explanation/ultimate solution for this issue.
Please also refer to @kebugcheckex’s comment. There’s a URL which roughly explains how apps can be purged from the system.
@develar, I ran in to this too and https://github.com/electron-userland/electron-builder/issues/4057#issuecomment-574823454 resolved it for me.
Are you interested in a PR to make this part of the default nsis install script? Happy to work on that.
The workaround by @o2genum and @rlugge worked for me, but interestingly, I needed to explicitly add
"include": "build/installer.nsh"in thensiskey ofpackage.json(runningv22.7.0(latest))@o2genum could you explain how to use that workaround? I’m getting what appears to be this problem (though we haven’t manually removed the files), but I don’t understand how to debug or fix it.
Apparently, in assisted mode the installer is meant to get stuck until cancelled.
It says “Installation Aborted” and “Setup was not completed successfully” and offers a “Cancel” button.
@Slapbox Sorry, my bad, with the latest electron-builder 22.8.0 issue persists indeed.
I updated my electron-builder and it worked for me only onсу because they changed the
Uninstall\{GUID}registry key back toUninstall\GUID. Looking into the sources.This seems to have been fixed by #3782 and #4674
Works with missing/fake broken uninstaller (with random bytes) and with installation dir emptied/removed.
@EmptyCrown I don’t think working with registry keys on Windows is that hard of a task electron-builder can’t handle. There should certainly be a way to make this automatic, that’s why we have “software”. But the way this issue is ignored is just sad.
Thanks, good to know. But on the other hand this is not a perfect fix, as the installer now has a name which isn’t clearly pointing out the version number.
How do you handle this situation, as i assume all your other builds do feature the version number in the filename
Something that helped me was running CCleaner as recommended by @kebugcheckex and then setting
"artifactName": "${productName}.${ext}".The default
artifactNamewas creating a slightly different installer name each time, which led to auto updates not overwriting the pre-existing program.