Make unpinning taskbar shortcuts optional during uninstall?

[Elewout Hallynck]

Hi,

When a previous version of our software is installed, the installer first runs the complete uninstall procedure before installing a new version, to make sure all previous files are properly cleaned up. However, when the user had pinned a shortcut to our application to the taskbar, it is always automatically removed during the uninstall process. This is, at least in our case, not ideal behaviour since the user wants to keep the pinned shortcut (he simply upgraded the software and wants to continue using it).

Since in recent versions of Windows 11 it has become difficult (not to say impossible) to automatically (re-)pin something to the taskbar without the user explicitly doing so, we were wondering if there would be a possibility to make the unpinning of the taskbar shortcut during the uninstall process (= the call to UnpinShellLink in the code) optional. We already detect whether a previous version is installed or not so, based on that, we could decide whether the shortcut should actually be unpinned (= in case of a true uninstall) or not (= in case of an upgrade).

Or, does someone see an alternative way around this issue?

Regards,

Elewout

[Gavin Lambert]

On Wednesday, April 29, 2026 at 10:39:03 PM UTC+12 Elewout Hallynck wrote:

When a previous version of our software is installed, the installer first runs the complete uninstall procedure before installing a new version, to make sure all previous files are properly cleaned up. However, when the user had pinned a shortcut to our application to the taskbar, it is always automatically removed during the uninstall process. This is, at least in our case, not ideal behaviour since the user wants to keep the pinned shortcut (he simply upgraded the software and wants to continue using it).

The recommended solution is to not perform an uninstall before installing; instead, keep track of which files should no longer exist after upgrade and add explicit [InstallDelete] entries (don't use broad wildcards and especially don't try to delete {app}\*).  A lot of the time, redundant files can just be left behind without harm (when the app won't get confused by stray files or registrations); most files are small and if it does annoy the user they can do the uninstall themselves. 

[Bill Stewart]

On Wednesday, April 29, 2026 at 5:54:06 PM UTC-6 Gavin Lambert wrote:

The recommended solution is to not perform an uninstall before installing; instead, keep track of which files should no longer exist after upgrade and add explicit [InstallDelete] entries (don't use broad wildcards and especially don't try to delete {app}\*).  A lot of the time, redundant files can just be left behind without harm (when the app won't get confused by stray files or registrations); most files are small and if it does annoy the user they can do the uninstall themselves.

IMO, this recommendation has its place but can be impractical depending on the complexity of the installer. (Gavin: I am aware you probably disagree with this assessment; we''ll just amicably agree to disagree.)

As I see it, the root problem is the difference between "I am uninstalling and do not intend to reinstall" vs. "this uninstall is happening as a part of an upgrade." I could envision passing a "uninstalling as a part of an upgrade" command-line parameter to the uninstall process that skips certain actions. I don't recall whether the uninstaller supports custom command-line parameters or not.

[Gavin Lambert]

On Friday, May 1, 2026 at 2:52:09 AM UTC+12 Bill Stewart wrote:

IMO, this recommendation has its place but can be impractical depending on the complexity of the installer. (Gavin: I am aware you probably disagree with this assessment; we''ll just amicably agree to disagree.)

I kind of agree but probably in the opposite direction that you expect: as the installer complexity increases, it becomes less and less practical to uninstall each time.  If your uninstaller takes ten seconds and just deletes a bunch of files it's a lot easier to justify doing it (though it's still not recommended practice), compared with one that takes half an hour and removes half a dozen components and a database only to put them back again afterwards.

 

As I see it, the root problem is the difference between "I am uninstalling and do not intend to reinstall" vs. "this uninstall is happening as a part of an upgrade." I could envision passing a "uninstalling as a part of an upgrade" command-line parameter to the uninstall process that skips certain actions. I don't recall whether the uninstaller supports custom command-line parameters or not.

Yes, you can still use {param:X} constants or ParamCount/ParamStr from InitializeUninstall or other uninstall event functions.

[Bill Stewart]

On Thursday, April 30, 2026 at 8:53:30 PM UTC-6 Gavin Lambert wrote:

Yes, you can still use {param:X} constants or ParamCount/ParamStr from InitializeUninstall or other uninstall event functions.

I thought so, but I couldn't remember for sure.

Since the parameter functions are available in the uninstaller, the OP could possibly use a command line parameter to indicate "I am uninstalling as a part of an upgrade" and behave differently in that case.

[Martijn Laan]

Hi,

Op 30-4-2026 om 16:52 schreef 'Bill Stewart' via innosetup:

IMO, this recommendation has its place but can be impractical depending on the complexity of the installer. (Gavin: I am aware you probably disagree with this assessment; we''ll just amicably agree to disagree.)

I agree with Gavin as well, and think he explained it very well.

Bill, I wonder what kind of complexity you mean and whether it could be addressed. Could you shed some light on this?

I would think [InstallDelete] is mostly good enough to handle files which no longer exist. There are some limitations that we could fix, like being able to 'unregisterserver'. Or are you thinking about other things? It must be things the uninstaller can do, but [InstallDelete] or [Code] cannot?

Greetings,
Martijn

[Martijn Laan]

Hi,

Op 29-4-2026 om 12:38 schreef Elewout Hallynck:

Or, does someone see an alternative way around this issue?

I suppose you could prevent uninstallation (and therefore unpinning) of the shortcut by using the uninsneveruninstall flag on its entry. Then, you could 'manually' uninstall and unpin from the [Code] section during uninstall, but only if it is not an upgrade. You could pass the uninstaller a special parameter and use {param:...} to detect that.

When a previous version of our software is installed, the installer first runs the complete uninstall procedure before installing a new version, to make sure all previous files are properly cleaned up

Why aren't you using [InstallDelete] to clean things up? Most end-users won't appreciate the delay of running the uninstall first, I think.

Greetings,
Martijn

[Elewout Hallynck]

Hi,

Thanks all for the replies and thanks for the suggestion!

We run the uninstall first to make sure that we start off with a "clean slate" before installing a new version. It's also something that was decided many years ago (back when we were still using NSIS for our installer) and we just stuck with it. And the uninstall only takes a few seconds on a typical desktop PC so, no one's really bothered by it.  But I get the argument for doing it the other, recommended way. Perhaps in the future we'll change it.

Regards,

Elewout

[Bill Stewart]

On Wednesday, May 6, 2026 at 12:15:03 AM UTC-6 Martijn Laan wrote:

Why aren't you using [InstallDelete] to clean things up?

One possible reason is that [InstallDelete] only deletes files. It doesn't undo other installer changes such as registry entries, services installed, etc. (Depending on the use case, an upgrade may need to remove things other than files.)

[Bill Stewart]

On Wednesday, May 6, 2026 at 12:08:56 AM UTC-6 Martijn Laan wrote:

Bill, I wonder what kind of complexity you mean and whether it could be addressed. Could you shed some light on this?

I would think [InstallDelete] is mostly good enough to handle files which no longer exist. There are some limitations that we could fix, like being able to 'unregisterserver'. Or are you thinking about other things? It must be things the uninstaller can do, but [InstallDelete] or [Code] cannot?

See documentation for UninsIS.dll[1] for some possible reasons why uninstalling before upgrading might be preferable (again, depending on the use case).

(I have received lots of thanks from users for writing this DLL as it seems to have made people's lives easier.)

[1] https://github.com/Bill-Stewart/UninsIS

[Gavin Lambert]

On Thursday, May 7, 2026 at 3:24:44 AM UTC+12 Bill Stewart wrote:

One possible reason is that [InstallDelete] only deletes files. It doesn't undo other installer changes such as registry entries, services installed, etc. (Depending on the use case, an upgrade may need to remove things other than files.)

In the majority of cases, these can remain.  In the few remaining cases, [Code] can do whatever is needed.