-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installing a new version leaves the old version #735
Comments
Known expected issue. But now I realised that is not ok because previously app was installed not per version (no version folder) and such files are not removed. But must be removed. |
Error because we require |
When I run the old installer, it creates this registry key: |
I don't have currently time to test all possible cases, auto test planned to finish. This case should be fixed. |
Another fix was pushed (yep, now we have integration tests for it). |
Wait. Maybe disregard the below, because I'm looking in /usr/local/lib/node_modules/electron-builder/templates/nsis/installSection.nsh and I don't see any of those changes from that commit. I guess that means this isn't in 6.7.3, right? I just repeated the steps from my report using the 6.7.3 version and the problem is still there. Looking at the code, I think this is the issue:
There is no such registry entry on my machine after running the 5.x installer. In fact, the only thing I see in the registry that says where the program is installed, is the path of the uninstaller, which you already have in |
When will this change be in the NPM registry so I can try it? |
@joshua-smith 6.7.3 is published, your note |
I'm confused by this whole GIT/NPM thing. Sorry. When I look at that commit, it's 140 lines of code, starting with
And I installed on my local machine with
And it says I have 6.7.3:
but when I look at
So it appears that while I have 6.7.3, I don't have the code you committed. |
@joshua-smith Your version is correct, master version has 111 lines of code — https://github.com/electron-userland/electron-builder/blob/master/templates/nsis/installSection.nsh Latest change to file |
But #722 is also closed. I'm just trying to understand where we are on the development path, because the people waiting on me are kind of freaking out about still not having an installer they can use. If you do that getParent thing tomorrow morning, how long until I see that in NPM? (I just want to emphasize that I'm not complaining about the process here. What you are doing is great. I'm just trying to understand the relationship between you closing bugs and those fixes showing up in NPM.) |
You will get Publish is automatic — every
No strict rule here — yes, I pushed new commit and linked it to #722 but I didn't reopen this issue — because my fix was just a better and more correct version of fix. Why not |
Cannot reproduce |
This problem is still present in 6.7.4. I see the call to GetFileParent, so I'm definitely running the new code. One thing I noticed looking at the registry is that you are generating a proper GUID automatically. The previous version just used the app name as the GUID. As a result, the old installer and the new installer have different GUIDs. I'm wondering if that's an issue? |
GUID logic was not changed. Please see https://github.com/electron-userland/electron-builder/wiki/NSIS#guid-vs-application-name I built per-machine installer using 5.30.0 and 6.7.3 correctly deletes it. |
Do you build the same app using different versions of electron-builder? Maybe |
The original installer was built using electron-builder and the config.json file I used didn't actually have a "name" attribute in it. It had a "title" attribute, which I suppose it used as the name. When I look at the old installer.nsi.tpl, it used ${APP_NAME} the way your new code uses ${PROGRAM_FILENAME}. When I went to the new version, it insisted that I needed a "name" attribute, however, it did not allow me to use the title as the name because the title had spaces. So now I'm setting the "name" attribute to the title, but with spaces converted to underscores. Looks like I was using electron-builder 2.7.1 before I upgraded. So that's probably why it's not working. The 2.7.1 version probably just installed things very, very differently than the 5.x version did. I'll do some experiments and look at the code, and get back to you... |
I can work around the GUID issue by setting nsis.guid to the application Title. That allows your code to find the uninstaller. However, you are invoking the uninstaller incorrectly. Per the documentation:
So this line:
Needs to be:
I moved the I tested this in a cmd window and it works correctly. (Note that the way you had it, uninstaller would actually delete the plugins folder!) |
"the last parameter used in the command line and must not contain any quotes, even if the path contains spaces"
I missed this doc, thanks a lot, but actually, why does it work for me? Anyway — change pushed. |
Yes. Completely differently. Because NSIS support was dropped in 3 version and restored in the 4 (completely rewritten). |
It is puzzling why it would work for you. The uninstaller I'm using, of course, is pretty old, since it's contemporary with 2.7.1 of electron-builder. Perhaps older uninstallers are more particular than the one you are including now? |
One last bug. This line:
Finds a string that doesn't have quotes around it. So when you call:
That leaves an empty string in
(No idea if that push/pop is a sane way of doing a variable assignment. I'm just guessing here.) |
|
If not quoted, so, it is incorrect (corrupted?) string and we just skip it. |
@joshua-smith Fixed. |
Confirmed that this is completely fixed in 6.7.7. Thank you! |
Steps to reproduce:
\Program Files\Something\
\Program Files\Something\{version}\
Expected result:
The files from the old installer should be removed
Observed result:
The old version is still there, and the new version is also there
There are two uninstallers listed in "Add/Remove Programs"
The desktop shortcut points at the right version
If you start the new installer with the old version still running, it does recognize that, and offer to kill the running application.
The main risk is that users who created their own shortcuts will continue to run the old version. The presence of two uninstallers will also be confusing to users.
My guess: The new code that moves the uninstaller out of the way #722 is not passing the right folder to the uninstaller when it invokes it.
The text was updated successfully, but these errors were encountered: