2

I'm struggling to understand how user pinned shortcuts in windows explorer work in relation to windows installer. I was under the impression that the User Pinned shortcuts were completely user handled, but it seems windows installer will find (and modify) user pinned shortcuts when installer shortcuts are removed.

This is basically two related questions, one relating to early scheduling of uninstall, and relating to late scheduling, and in particular changing from early to late between versions.

Cached "internal" icons from msi's still work after upgrade

Example: Application v1.0 installs a non-advertised shortcut on the desktop, and uses an icon internal to the msi. The user then does "pin to taskbar". Both the taskbar and the desktop shortcut now references an icon copied from the msi into the icon cache, such as %SystemRoot%\Installer\{CB24D097-4E8F-4E8E-8FE3-EACF5954DE56}\MyApp.ico. Application is upgraded to v2.0 via a Major upgrade with late scheduled removal of v1. The user pinned shortcut will not be corrupted/removed, it keeps the same icon even though the icon (presumably?) belonged only to the v1 installer? Why does this work? Is there ever a risk that the cached icon will be removed in the future, thereby corrupting the user pinned shortcut?

Early scheduling of uninstall corrupts user pinned shortcuts

If application is upgraded from v1.0 to v2.0 with a Major Upgrade using an early uninstall of the previous version, then as the application (temporarily) removes the installer-provided shortcut on the desktop, something also corrupts the user pinned shortcut. The only workaround I have found (short of programatically hacking shortcuts back into place) is to make the installer not remove shortcuts at all, instead removing the .lnk via doing a <RemoveFile on="uninstall"> for the shortcut. (See Wix - Do Not Remove Pinned Taskbar on Install) Now, this hack works well enough for a chain of major upgrades that all have uninstall scheduled early, and as described in the previous paragraphs - late scheduling seems to always work even without hacks-

However, what if v1.0 is already shipped with late uninstall, and v2.0 is the first upgrade to uninstall the previous version early?

Is there any way I can influence the uninstall of v1.0 in the V2.0 msi? Specifically, can I somehow persuade the v1.0 uninstall to skip the remove shortcuts step?

Community
  • 1
  • 1
Anders Forsgren
  • 10,827
  • 4
  • 40
  • 77
  • Well, unfortunately, i cannot think of a more elegant way to achieve what you are trying to do. We have had such issues and the only way you could do that is to modify the cached msi of v1.0 from v2.0 of the msi package,before the upgrade process initiates the uninstall of v1.0. This would mean that instead of entirely disabling the RemoveShortCuts action , you could use conditions such as NOT UPGRADINGPRODUCTCODE against RemoveShortCuts in the v1.0 cached msi package, so that this action does not get triggered during an uninstall happening as part of a major upgrade. – Kiran Hegde Sep 01 '15 at 08:50
  • Thanks, can you point me to somewhere where it is described how to modify the already deployed v1 installer? – Anders Forsgren Sep 01 '15 at 10:04
  • You can include in your v2.0 package just the fixed MSI (no cabs) of v1.0. Then recache it with a simple custom action that calls this command: http://www.advancedinstaller.com/user-guide/faq-misc.html#question129 – Bogdan Mitrache Sep 01 '15 at 14:41
  • Thanks, that's unfortunately not an option for this msi because of the size (hundreds of megs) but will keep in mind for next time I need to do that. This one will have to be patched in-place. – Anders Forsgren Sep 01 '15 at 18:59

0 Answers0