electron-builder: NSIS installer always show "XYZ cannot be closed. Please close it ..." when there is other process name contains "XYZ"
- Electron-Builder Version: 23.0.3
- Node Version: 16.3.1
- Electron Version: 16.2.5
- Electron Type (current, beta, nightly):current
- Target: Windows 11
In my case, productName of my project is XYZ, it allows user to install a service named XYZ Helper on Windows, which runs when the operating system starts up. When I use electron-builder(23.0.3) to package(target: NSIS), the installer always show XYZ cannot be closed. Please close it manually and click retry to continue. even after I’m sure to quit XYZ completely. Only after I also stop the service named XYZ Helper, this step can be processed. But XYZ Helper is not part of XYZ, which is a separated process and should not be stopped. electron-builder(22.14.13) doesn’t have this problem.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 13
- Comments: 34 (4 by maintainers)
Commits related to this issue
- Downgrading the electron-builder to avoid https://github.com/electron-userland/electron-builder/issues/6865 — committed to enso-org/enso by mwu-tow 2 years ago
- Adjusting CI / build configuration. (#3664) * Downgrading the electron-builder to avoid https://github.com/electron-userland/electron-builder/issues/6865 * Removed "git clean" workaround from CI. — committed to enso-org/enso by mwu-tow 2 years ago
- Fixing yargs and electron-builder regressions (#3725) This PR reverts two version bumps from #3712: * `yargs` needs to be downgraded, because a never version can trigger https://github.com/evanw/esb... — committed to enso-org/enso by mwu-tow 2 years ago
- fix(project): downgrade electron-builder See https://github.com/electron-userland/electron-builder/issues/6865 — committed to hyrious/flat-desktop by hyrious a year ago
- fix(project): downgrade electron-builder (#1813) See https://github.com/electron-userland/electron-builder/issues/6865 — committed to netless-io/flat by hyrious a year ago
- fix: pinned `electron-builder@22.14.13` Ref: electron-userland/electron-builder#6865 Closes: #1801 Signed-off-by: Akos Kitta <a.kitta@arduino.cc> — committed to arduino/arduino-ide by deleted user a year ago
- Bump `electron-builder` on CI macOS runners. (#8284) This PR avoids #8119 by selectively bumping the `electron-builder` on macOS CI runners. We do this only on macOS, as we do not want to trigger htt... — committed to enso-org/enso by mwu-tow 7 months ago
Quick note. This was added to resolve these (based off the commit message): #4898 If the path contains Chinese characters, packaging will fail. #6232 shortcutName in chinese #6259 Random code After packing
I’m wondering if there’s a way for us to identify it other than “contains” and instead look for an exact match? Not sure if that’s where the bug is originating though.
At a base level, my apologies for this issue being stagnant. I’ve been the only maintainer on this project for some time now and am largely dependent upon community contributions, especially when relating to windows and linux (I’m predominantly a mac user).
Hi. Any solutiuon exist or need to downgrade?
This problem does not exist on version 22.14.13 or previous.
I’m having this issue also, tried most of the fixes suggested but the only thing that worked was reverting to “electron-builder”: “22.14.13”
Ok, as a temporary solution I did this in my
package.json:…meaning that every time I initiate the build for Windows - I also rollback to the working electron-builder version (22.14.13)
Same issue. Fixed with CRCCheck off https://github.com/electron-userland/electron-builder/issues/6409
Alright, more info. Our installation contained a file with a really long file path (247 characters long). This caused the rename operation to fail on some machines (depending on the user name, where the temp dir is, etc). It probably reached the 256 limit when trying to rename it and failed.
It seems that when the uninstaller fails, the installer assumes it’s because the app is still running, giving a wrong error message?
Not sure about the above statement ^, but it wouldn’t surprise me if that’s the culprit of many failures that were reported here.
We’ve (https://www.codux.com/) been hit quite hard with this one. Several of our users have reported failures to install our new version over the old one with the same error dialog. The uninstaller, which gets launched by the installer, fails 5 times. Launching the uninstaller manually from “Apps/Installed-Apps/Add-Remove” works.
Our investigation found several possible changes that caused this: https://github.com/electron-userland/electron-builder/pull/6551 https://github.com/electron-userland/electron-builder/pull/5902
We’ve forcibly ran the uninstaller in non-silent mode from installer (e.g. removed the /S) and saw it failing to remove the application directory.
Tried several workarounds. We’re currently trying to define
customRemoveFilestoRMDir /r $INSTDIRand see if it helps.EDIT: we’re adding the following .nsh script using
electronBuilderConfig->nsis->include:Hi! Any ideas how to resolve the issue? None of the proposed approaches currently solve it for my Windows users. And I can’t downgrade the version because of necessary features for “universal” Mac build((
… meaning that every time user sees an “update available” in my app - when installing on Windows this error appears - “App cannot be closed. Please close it manually and click Retry to continue”
I’m using
nsisWebinstallerHi @mmaietta thanks for your reply.
As for the first solution, I am not able to use the first solution with
perMachine: true. It has a problem with/alluserssuffix in uninstallstring as you can see here #7472 So I had to useperMachine: false.As for the second solution, I would like to edit my npm package
app-builder-libwith your custom code from patch version. Before I use your code, I have questions.nsExec::Execcmd /c tasklist /FI “USERNAME eq %USERNAME%” /FI “IMAGENAME eq ${_FILE}” -fo csv | convertfrom-csv``Why do I have to replace
| find "${_FILE}with-fo csv | convertfrom-csv?For the developer picking this up, somehow FIND_PROCESS inside
packages/app-builder-lib/temapltes/nsis/include/allowOnlyOneInstallerInstance.nshsays that a process is running while if you execute the same command in the command line, it reports nothing is running. It gets stuck because it reports there is a process active but it can’t kill any of the processes as there are non active which causes you to be stuck in an infinite loop.EDIT 2: Alright so the issue is the following: the exit code of FIND_PROCESS is 0. This is probably because there is a parent process active which doesn’t fall under the same name. It’s on admin level so the user can’t close it as it doesn’t know the name, we can’t close it as it’s on admin level and it keeps looping. I think the solution to this problem is to show a list of running processes and display the list of processes blocking the installer instead of a simple retry.
Edit: Seems I have found it. When I have the installer “test-app-installer.exe” open for “Test App.exe” for an one click installation for an user installation, the allowOnlyOneInstallerInstance.nsh calls FIND_PROCESS which execs the following command:cmd /c tasklist /FI "USERNAME eq %USERNAME%" /FI "IMAGENAME eq Test App.exe" | %SYSTEMROOT%\System32\find.exe "Test App.exe". While having the installer open, I check this command inside my cmd and it returns 0 as exit code (so blocking installation) but if I look at the result, there are no processes active (clear result)