Fix Windows MSI uninstallation issue whereby shortcut does not get removed when more than one version is installed #7701
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bergmeister
changed the title
…The Component/@Guid attribute's value '*' is not valid for this component because it does not meet the criteria for having an automatically generated guid. Components using a Directory as a KeyPath or containing ODBCDataSource child elements cannot use an automatically generated guid. Make sure your component doesn't have a Directory as the KeyPath and move any ODBCDataSource child elements to components with explicit component guids)
bergmeister
changed the title
TravisEz13
reviewed
Sep 4, 2018
Member
TravisEz13
left a comment
TravisEz13
left a comment
There was a problem hiding this comment.
You might want to add a comment that * means that the GUID is auto-generated
TravisEz13
approved these changes
Sep 4, 2018
anmenaga
approved these changes
Sep 5, 2018
|
Restarted failed 'PowerShell-CI-macos' run. |
TravisEz13
pushed a commit
that referenced
this pull request
Sep 7, 2018
…ne version is installed (#7701) Fixes underlying problem of #3341. Related: #2881 When multiple versions (e.g. RTM and preview) of PowerShell are installed via the MSI and one is being uninstalled, then the start menu shortcut does not get removed due to the shortcut component being not unique per version. This also applies to an upgrade scenario. Therefore use an auto-generated Guid (`*`)
10 tasks
TravisEz13
pushed a commit
that referenced
this pull request
Apr 7, 2019
Fixes #8919 Preserve user shortcuts pinned to Taskbar during MSI upgrade by not removing shortcuts in this case (assuming the user has not changed the installation directory), see https://stackoverflow.com/a/33402698/1810304 This also requires the Guid to not always be re-generated, which PR #7701 originally added to ensure shortcuts get removed when RTM and preview are installed, the underlying problem was rather that RTM and preview shared the same GUIDs, therefore the GUIDs are hard-coded again but different for RTM and preview, therefore the shortcuts will still always get removed on uninstall. But this also means those GUIDs should change when the default installation directory changes, i.e. in PowerShell 7. Should we write the code to already take this into account that it does not get forgotten? Tested by first reproducing the issue by building installers locally (and bumping the patch version. Then the fix was applied to verify the solution, it. For this to take effect the version from which an MSI is being upgraded must have this fix already, i.e. if this fix got shipped in `6.2.1`, then on upgrading to it, the issue would still occur but when upgrading `6.2.1` to `6.2.2` the shortcut would start being preserved. I am wondering if we could maybe improve this to show effect earlier by trying to extract the used (auto-generated) GUIDs in the `6.2.0` and `6.2.0-rc` packages out and use them... Please not that we probably need to take this out for `7.0` because the base installation directory will change. This also assumes that the user has not specified a different installation directory on upgrade but this is a bit of an edge case where I think other things might break as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Summary
Fixes underlying problem of #3341. Related: #2881
When multiple versions (e.g. RTM and preview) of PowerShell are installed via the MSI and one is being uninstalled, then the start menu shortcut does not get removed due to the shortcut component being not unique per version. This also applies to an upgrade scenario. Therefore use an auto-generated Guid.
The same scenario also applies to the explorer context menu Guid here but this cannot be fixed in the same way due to this compilation error and will need to be addressed in a 2nd PR (
LGHT0230 : The Component/@Guid attribute's value '*' is not valid for this component because it does not meet the criteria for having an automatically generated guid. Components using a Directory as a KeyPath or containing ODBCDataSource child elements cannot use an automatically generated guid. Make sure your component doesn't have a Directory as the KeyPath and move any ODBCDataSource child elements to components with explicit component guids)cc @SteveL-MSFT @joeyaiello as this PR is a candidate for 6.1
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests