Electron-builder: When updating the Electron App the Pinned Icon from Taskbar is removed

[mastergberry]

• Version: Latest

• Target: Windows (Nsis)

When you are doing an update the NSIS system seems to remove the pinned icon (if you pinned it) on your task bar (bottom of screen). Is there some way to make it so when upgrading this icon is not removed?

[develar]

Well, in general, it was fixed. I mean — if some configuration is not changed, shortcuts will be not recreated and so, pinned icon remains. In your case, it seems, shortcut related configuration detected as changed and it leads to icon reregistration. Please provide your NSIS config.

[mastergberry]

The problem is the pinned icon is being removed from the task bar. The icon appears on the desktop again...but it's just removed from the bottom bar in windows.

"nsis": {
      "oneClick": false,
      "perMachine": true,
      "allowElevation": true,
      "allowToChangeInstallationDirectory": true,
      "runAfterFinish": false,
      "include": "build/badlion.nsh",
      "unicode": true,
      "differentialPackage": true
    },

[mastergberry]

Just for further clarification @develar in case something wasn't clear with the way windows words things:

Before Upgrading to 1.1:

After Upgrading from 1.0 to 1.1:

In the first part of the upgrade it seems to remove the existing icon from the task bar.

[develar]

Reproduced.

[mastergberry]

Any chance of getting this resolved soonish @develar? If not can you point me to where you think the issue is happening so I can try to take a crack at it. Don't have an environment at the moment but I will in a few days.

[PSNRigner]

allowToChangeInstallationDirectory: true
Looking at the code, it looks like when enabling this setting, keepShortcuts bool is automatically set to false.
https://github.com/electron-userland/electron-builder/blob/2dda5fcb45d99a0a991d195a2f577e3dbca775eb/packages/electron-builder-lib/templates/nsis/include/installer.nsh#L251

I don't think this is not how it should be working, if the installation path, app args etc didn't change between old and new shortcut, it shouldn't recreate it. It's just missing a shortcut "content" check around here.
https://github.com/electron-userland/electron-builder/blob/2dda5fcb45d99a0a991d195a2f577e3dbca775eb/packages/electron-builder-lib/templates/nsis/include/installer.nsh#L222

(might need to check other installers for similar mistakes ?)
(I have no knowledge about NSIS, i don't know how to make these changes myself)

[Jandou6]

The Bug is also in Latest(Version 20.19.x)

[tobiasmuecksch]

This bug is still present.

[tobiasmuecksch]

Has anyone found a solution or workaround?

[PSNRigner]

Hello, no we didn't find any yet.

http://nsis.sourceforge.net/ShellLink_plugin#DLL_Functions

After looking a bit at this plugin, it should be able to do what i described above, allowing us to check the content of a shortcut, to avoid recreating it if that's not needed.

I'm tagging @develar for this, he would know more than me what should be done, as I have no knowledge in NSIS.
Maybe add a new option to keep shortcuts if nothing changed in them, or even use the ShellLink::SetShortCut* methods instead of recreating the file.

[Kelin2025]

Any updates here? Still have this problem

[rgk1]

We're getting user reports of this, would be grateful for any updates? thanks

[mattlyons0]

I believe in NSIS WinShell::UninstShortcut is what removes pins. See: https://github.com/electron-userland/electron-builder/search?q=uninstshortcut&unscoped_q=uninstshortcut

You might be able to replace the default NSIS script with that line removed and be able to fix this for yourself. IIRC the reason this happens is because the uninstall script isn't aware of the fact that the program will be immediately reinstalled and/or the new install version might not have the same install path so this ensures shortcuts are updated (which has the side effect of removing pins).

This is based on my knowledge of this and similar issues from 2 years ago, take with a grain of salt but it appears to still be relevant.

[Stanzilla]

@develar you said you reproduced it, any pointers to what the problem is?

[Jacobkg]

Anything the community can do to help get this fixed?

[Jacobkg]

We made a donation to encourage development on this issue

[develar]

@Jacobkg Do you also use allowToChangeInstallationDirectory? Please provide your NSIS config.

[Stanzilla]

We use the 100% default config and still have this issue.

[Jacobkg]

@develar We do not have that key in our settings. Our Config is:

win:
  artifactName: 'WorkFlowy-Development-Installer.${ext}'
  target: nsis

I just confirmed that the issue is still happening on Windows 10 with

"electron": "3.1.6",
"electron-builder": "20.38.5",
"electron-updater": "^4.0.6"

We pin the app to the taskbar and when the autoupdate completes (app is closed, installs, and restarts) then it is no longer pinned to the taskbar.

If it helps I can point you to a public download of our app that exhibits the issue

[tobiasmuecksch]

Anything new on this issue?

[boytimmers]

Solution/workaround:

In package.json:

  "build": {  
    "nsis": {
      "include": "build/installer.nsh"
    }
  }

Create build/installer.nsh as such (I've put this in my public folder so it gets build into the build folder):

!macro customInstall
  ${StdUtils.InvokeShellVerb} $0 $INSTDIR "${APP_FILENAME}.exe" ${StdUtils.Const.ShellVerb.PinToTaskbar}
!macroend

[boytimmers]

@Jacobkg @tobiasmuecksch @Stanzilla @rgk1 @Kelin2025
Please check if above workaround resolves this issue for you.

Note that this is intrusive behaviour because this forces the installed app to be pinned to the taskbar.

[Jacobkg]

@boytimmers I appreciate the suggestion. Unfortunately we don't want to pin to the taskbar for users that didn't choose to do so themselves.

[pashvin]

Here is my suggestion how to fix this issue.

Windows store pinned icon at C:\Users\<\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User PinnedTaskBar as a link file. Before start installation (for upgrade it will first uninstall which will clean original link file) save the link file (can rename or move into parent folder) and after installation complete, check if saved file exist. If it does, then restore it.

For fresh install , the saved file will not exist and that will save us from creating pin icon for fresh installation.

[tobiasmuecksch]

Anything new on this issue? My users are pretty annoyed and keep reporting it...

[tjfryan]

I spent some time debugging this and it seems to come from the addDesktopLinks macro during install. So, here are some things I found that resolved the issue (on a per-app basis):

• Delete the automatically created desktop shortcut. Because when createDesktopShortcut is its default value of true, it will skip the macro if the shortcut generated from the initial install is no longer present. When re-installing after deleting the desktop shortcut, the taskbar item remains. This is really only a good solution if you're not the maintainer of the app, and are experiencing this problem as a client.

• (The better solution, imo) Set createDesktopShortcut to false in your electron-builder config. This skips the macro entirely and doesn't delete the taskbar shortcut. The end user is free to make their own desktop shortcut if they desire.

Hopefully this helps anyone wanting to fix this issue on their own app or wanting to submit a pull request.

[lewisgauss]

I spent some time debugging this and it seems to come from the addDesktopLinks macro during install. So, here are some things I found that resolved the issue (on a per-app basis):

• Delete the automatically created desktop shortcut. Because when createDesktopShortcut is its default value of true, it will skip the macro if the shortcut generated from the initial install is no longer present. When re-installing after deleting the desktop shortcut, the taskbar item remains. This is really only a good solution if you're not the maintainer of the app, and are experiencing this problem as a client.
• (The better solution, imo) Set createDesktopShortcut to false in your electron-builder config. This skips the macro entirely and doesn't delete the taskbar shortcut. The end user is free to make their own desktop shortcut if they desire.

Hopefully this helps anyone wanting to fix this issue on their own app or wanting to submit a pull request.

I tried this, but another bug appears as a result...
After updating, the taskbar shortcut remains, but the application icon becomes an empty white square. Any idea on solving this?

[froatsnook]

@lewisgauss: I am experiencing the same behavior. I plan to use boytimmer's intrusive solution until a workaround/fix is found.

[tjfryan]

Ah, yes, it looks like I've run into this issue as well. When testing my solution, I was only installing the same version of my app over and over. It looks like once I installed a version with a more recent number, it left the taskbar entry in place, but turned it into the generic white icon.

[tCharlesworth]

I recently found myself with this same issue.
After researching a few similar issues to what was being discussed here I found this solution which is intrusive like boytimmer's solution however it links the start menu link instead of the exe file. I will add the link here so you can see the discussion on that thread too.

https://github.com/electron-userland/electron-builder/issues/1084#issuecomment-305169451

[Ahriana]

just had a report of this too

electron-builder@^21.2.0
electron-updater@^4.2.0
electron@^7.1.7

might be possible to detect if the app is pinned and repin it after update however this might have other issues, i might come back if i find a work around that works for now

[ibnyusuf]

Solution/workaround:

In package.json:

  "build": {  
    "nsis": {
      "include": "build/installer.nsh"
    }
  }

Create build/installer.nsh as such (I've put this in my public folder so it gets build into the build folder):

!macro customInstall
  ${StdUtils.InvokeShellVerb} $0 $INSTDIR "${APP_FILENAME}.exe" ${StdUtils.Const.ShellVerb.PinToTaskbar}
!macroend

Anything further on this issue? I am facing the same and even this intrusive fix is not working. My package.json :

"build": {
    "publish": [
      {
        "provider": "generic",
        "url": "url"
      }
    ],
    "appId": "MyAppID",
    "dmg": {
      "contents": [
        {
          "x": 110,
          "y": 150
        },
        {
          "x": 240,
          "y": 150,
          "type": "link",
          "path": "/Applications"
        }
      ]
    },
    "linux": {
      "target": [
        "AppImage",
        "deb"
      ]
    },
    "nsis": {
      "include": "./installer.nsh"
    },
    "win": {
      "publisherName": "name"
    }
  },

And the content of installer.nsh:

!macro customInstall
  ${StdUtils.InvokeShellVerb} $0 $SMPROGRAMS "MyAppname.lnk" ${StdUtils.Const.ShellVerb.PinToTaskbar}
!macroend

[lwestfall]

Voicing my interest in a fix as well. The intrusive work-around is not suitable for my application, so it'd be super nice to have the ability to only pin the shortcut if the user had it pinned in the previous version. Looking forward to hearing more on this issue at some point.

[evangelistagrace]

I spent some time debugging this and it seems to come from the addDesktopLinks macro during install. So, here are some things I found that resolved the issue (on a per-app basis):

* Delete the automatically created desktop shortcut. Because when `createDesktopShortcut` is its default value of true, it will skip the macro if the shortcut generated from the initial install is no longer present.  When re-installing after deleting the desktop shortcut, the taskbar item remains.  This is really only a good solution if you're not the maintainer of the app, and are experiencing this problem as a client.

* (The better solution, imo) Set `createDesktopShortcut` to false in your electron-builder config.  This skips the macro entirely and doesn't delete the taskbar shortcut.  The end user is free to make their own desktop shortcut if they desire.

Hopefully this helps anyone wanting to fix this issue on their own app or wanting to submit a pull request.

This worked like a charm for me. Cheers!

[sandeep1995]

anyone have a fix for this ?

[EtienneLem]

anyone have a fix for this ?

https://github.com/electron-userland/electron-builder/pull/5312 claims to be fixing this issue. Change is pretty trivial and makes sense to me at first sight.

[anatoliyarkhipov]

@EtienneLem Is there something we can do to push the PR forward? 🤔

[EtienneLem]

@anatoliyarkhipov I would assume forking and testing the PR could be a first step, making sure it works. If a lot of people claim it is working on different Windows machine it would maybe make the PR a no-brainer to merge.

[1nfility]

I'm also having this problem on version 22.9.1.