-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Remove duplicate Open Here context menu item upgrading to newer Preview release
#8496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
4fc3ed1 to
6b4c86b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review: Looks ok to me from a code perspective, a manual test for the 2 scenarios (old context menu does exist or not) would not hurt though. Thanks for taking on the effort for this.
About the issue itself:
- I have seen the start menu failing to uninstall in one of the 6.1 previews, which I believe is the root cause to be of the reported issue.
- When I did the PR to tweak the registry setting to fix a subtle bug with it, I manually tested multiple upgrade scenarios by building 2 installers of different minor version and upgrading from one to the other and there was no issue. Therefore I suspect that maybe the simplification of the installation path to just have the simple version number
6broke that uninstall functionality on upgrade or something similar that impacted the whole installer? It would be interesting to construct a 6.2 installer and upgrade from an actual 6.1 RTM installer to test this scenario more realisticaly and verify this is actually an issue and not an intermittent issue in one of the previews (the nature of previews is simply that one should expect that sometimes something gets left over). This is the only reason why I have a bit of an odd feeling about adding such code but I'm OK with it if that's your preference. - Given the recent upgrade issue with shared components across RTM and preview, this could've also been a potential culprit. In PR #7701 I fixed for example the long standing issue where the shortcut did not get removed when RTM and preview were installed, which was due to the component GUID being shared and not unique. All of that just shows the potential of where upgrades can go wrong, maybe it would be better to recommend to always uninstall and re-install PowerShell (and potentially even disable upgrade?) if the expense of upgrade problems/maintenance outweighs the simplicity of upgrades? Since
WiXis being developed by MSFT, maybe an internal code review of the whole installer from experts likeRob Mensching(Github handle:@robmen) would be a good long term investment. - What kind of upgrade scenarios will PowerShell support? Just upgrading one minor or multiple patch versions at a time? Or multiple minor versions like e.g.
6.0.5->6.3.1? If there was a limitation then one could limit the lifetime of such workarounds to avoid accumulating a lot of those things over time.
|
@bergmeister thanks for looking into this. Our plan is to move to MSIX (post 6.2) so I don't think we want to spend a bunch of time trying getting things perfect now. |
|
@iSazonov I think we're good to merge this one |
|
This issue will still affect users that upgrade to the latest PoSh Core 6.2.x and once had a preview release. Suggestion if the directory and WMI call results there is no 6 preview installed cleanup should purge the orphaned registry keys. |
|
@Karl-WE If I remember correctly a conclusion was to do not fix the old and rare issue. Also taking in account how msi works it is not easy. |
|
I have searched the entire registry for How can we remove this manually? |
|
Yes, of cause. You need to search "pwsh.exe" |
|
The registry keys are here: Line 186 in bf59561
Alternatively, you can also just install a preview of 6 again with the explorer context menu again and uninstall it explicitly, which will always remove the registry entries, it is just the case of using an upgrade install, which can leave registry entries behind. I agree with @iSazonov that we should not need to invest effort for more polished previews, that's just the nature of previews (saving time for the dev team to get early feedback without having to invest time in proper support). |
|
Hi all I've made a script to remove this issue. It worked for me, hope it can help others. Cleanup-PowershellCoreOrphans.zip Tried to paste the code here but formatting didn't worked out as I expected so sorry for the zip file. |
|
I wrote something similar that will remove entries for all PowerShell versions that are no longer installed. Hope this helps. |
|
I too made a little PowerShell script to clean up right click context menus. Click to expand#Requires -RunAsAdministrator
<#
.SYNOPSIS
Clean up right click context menu.
.NOTES
Author: Olav Rønnestad Birkeland
Created: 210828
Modified: 210828
.EXAMPLE
# Git
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'git*'
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'git*' -WriteChanges
# Intel Graphics Settings
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'igfx*'
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'igfx*' -WriteChanges
# MPC-HC
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'mplayerc64.*'
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'mplayerc64.*' -WriteChanges
# nVidia Graphics Settings
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'NvCplDesktopContext'
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'NvCplDesktopContext' -WriteChanges
# PowerShell 7 Preview
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'PowerShell7-preview*'
& $psISE.'CurrentFile'.'FullPath' -NamesLike 'PowerShell7-preview*' -WriteChanges
#>
# Input parameters
[OutputType($null)]
Param(
[Parameter(Mandatory, HelpMessage = 'String array of PowerShell -like statements to match with.')]
[string[]] $NamesLike,
[Parameter(HelpMessage = 'Whether to write changes.')]
[switch] $WriteChanges
)
# PowerShell preferences
$ErrorActionPreference = 'Stop'
$InformationPreference = 'Continue'
# Assets
$Paths =
# Loop through
$(
[string[]](
'HKEY_CLASSES_ROOT'
)
).ForEach{
[string[]](
# Directory
('Registry::{0}\Directory\Background\shell' -f $_),
('Registry::{0}\Directory\Background\shellex\ContextMenuHandlers' -f $_),
('Registry::{0}\Directory\ContextMenus' -f $_),
('Registry::{0}\Directory\shell' -f $_),
('Registry::{0}\Directory\shellex\ContextMenuHandlers' -f $_),
('Registry::{0}\Directory\shellex\DragDropHandlers' -f $_),
# Drive
('Registry::{0}\Drive\shell' -f $_),
('Registry::{0}\Drive\shellex\ContextMenuHandlers' -f $_),
('Registry::{0}\Drive\shellex\DragDropHandlers' -f $_),
# Library folder
('Registry::{0}\LibraryFolder\background\shell' -f $_),
('Registry::{0}\LibraryFolder\background\shellex\ContextMenuHandlers' -f $_),
('Registry::{0}\LibraryFolder\ShellEx\ContextMenuHandlers' -f $_)
)
}.ForEach{
Get-ChildItem -Path $_ -Depth 0
}.'PSPath'.Where{
$(
foreach ($NameLike in $NamesLike) {
$_.Split('\')[-1] -like $NameLike
}
) -contains $true
}.ForEach{
Write-Information -MessageData $_
if ($WriteChanges) {
if (Test-Path -Path $_) {
$null = Remove-Item -Path $_ -Recurse -Force
Write-Information -MessageData ('{0}Successfully removed.' -f "`t")
$null = Start-Sleep -Milliseconds 100
}
else {
Write-Information -MessageData ('{0}Already removed.' -f "`t")
}
}
} |
|
Hi Steve @SteveL-MSFT do you think one these scripts could be included in the MSI? Not sure about Win11 as so far the integration due Windows Terminal is better and context menu only includes Terminal by default. |

PR Summary
Explicitly remove the old
Openregkey that enabled theOpen Herecontext menu functionality as it was renamed toOpenPwshand MSI didn't automatically remove the old key.@bergmeister can you help review as @TravisEz13 is on vacation currently
Fix #8290
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