'Proper way to customize Shortcuts creation ("Create Desktop shortcuts" checkbox)
According to MSI documentation in order to create a shortcut to an executable one needs to add an entry to the Shortcut Table and reference a Component in a Component_ column:
The external key into the first column of the Component table. The installer uses the installation state of the component specified in this column to determine whether the shortcut is created or deleted. This component must have a valid key path for the shortcut to be installed. If the Target column contains the name of a feature, the file launched by the shortcut is the key file of the component listed in this column.
My firts thought was to reference a component that is designated for an executable the shortcut is created for (as it is shown in the doc's example). It works as expected for installation, upgrade and uninstallation.
For an upgrade it is consistent and simple to maintain since it will automatically replace old shortcuts with the new ones if the component's code is changed.
But then I realized that now I can't configure the shortcut creation behavior: shortcuts will always be created. But it must be customizable during an installation via checkboxes ("Create desktop shortcuts", "Add shortcuts to ProgramFolder").
Solution 1
I have a really old legacy project that implemented this logic via a special component for Desktop Shortcuts whose installation depends on a condition. And it causes problems during upgrades, especially when shortucts are changed in the next version:
- old shortcuts not deleted
- new shortcuts may not be created
As you can notice, KeyPath is empty, so Directory_ is used as a key path for the components. I can't imagine what consquences it may have during upgrades when I change the ComponentId (I need old shortcuts to be removed).
To sum up: I don't like this approach one bit since one have to track 2-3 times as much components when dealing with executables and their shortcuts. And I can't make it work predictably.
Solution 2
This one is also a workaround. A custom action is added that modifies the Shortcut Table of the installation conditionally removing or adding the shortcut entries. I can't say that I like this a lot more than the first one. Also I can't predict how it would affect upgrades or repairs.
Conclusion
- Is there a proper (3rd) way to implement a customizable behavior for shortcuts creation to different destinations?
- What has to be done in order to make Solution 1 work predictable and modifiable in a consistent way? Changing shortcuts on updates.
- Is the second aproach legit or should it be avoided at all costs? (being practically worse than the 1st)
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|