Skip to content

Conversation

@SteveL-MSFT
Copy link
Member

@SteveL-MSFT SteveL-MSFT commented Dec 20, 2018

PR Summary

Explicitly remove the old Open regkey that enabled the Open Here context menu functionality as it was renamed to OpenPwsh and MSI didn't automatically remove the old key.

@bergmeister can you help review as @TravisEz13 is on vacation currently

Fix #8290

PR Checklist

remove old `Open` regkey
Copy link
Contributor

@bergmeister bergmeister left a 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 6 broke 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 WiX is being developed by MSFT, maybe an internal code review of the whole installer from experts like Rob 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.

@SteveL-MSFT
Copy link
Member Author

@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.

@SteveL-MSFT
Copy link
Member Author

@iSazonov I think we're good to merge this one

@iSazonov iSazonov merged commit e787027 into PowerShell:master Dec 27, 2018
@iSazonov iSazonov added the CL-BuildPackaging Indicates that a PR should be marked as a build or packaging change in the Change Log label Jan 17, 2019
@Karl-WE
Copy link

Karl-WE commented Oct 13, 2019

This issue will still affect users that upgrade to the latest PoSh Core 6.2.x and once had a preview release.
It will also not be cleared for those that upgrade any PoSh Core Preview.

Suggestion
please implement a cleanup with the next release of PoSH 6.x or 7.x, no matter if the user checks the explorer integration
The MSI can check if preview-6 is still installed by wmi check and directory check on
C:\Program Files\PowerShell\6-preview

if the directory and WMI call results there is no 6 preview installed cleanup should purge the orphaned registry keys.

image

@iSazonov
Copy link
Collaborator

@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.

@Karl-WE
Copy link

Karl-WE commented Oct 13, 2019

I have searched the entire registry for
"PowerShell 6-preview" but no finds.

How can we remove this manually?

@iSazonov
Copy link
Collaborator

Yes, of cause. You need to search "pwsh.exe"

@bergmeister
Copy link
Contributor

The registry keys are here:

<Component Id="ExplorerContextMenu" Guid="{df82e941-fced-4de9-aef8-c81a2946dd68}" KeyPath="yes">

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).

@SteveL-MSFT SteveL-MSFT deleted the msi-open-here branch October 14, 2019 16:27
@Karl-WE
Copy link

Karl-WE commented Oct 15, 2019

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.

@sba923
Copy link
Contributor

sba923 commented May 18, 2020

I wrote something similar that will remove entries for all PowerShell versions that are no longer installed. Hope this helps.

Remove-PowerShellOpenWithEntries.zip

@o-l-a-v
Copy link

o-l-a-v commented Aug 28, 2021

I too made a little PowerShell script to clean up right click context menus.
Run with -WriteChanges to actually remove anything.

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")
        }
    }
}

@Karl-WE
Copy link

Karl-WE commented Aug 28, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-BuildPackaging Indicates that a PR should be marked as a build or packaging change in the Change Log

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PowerShell-6.2.0-preview.2-win-x64 creates duplicate "Open here" context menu item (also preview.3)

6 participants