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

[najeebanwer]

Steps to reproduce

Install PowerShell-6.2.0-preview.2-win-x64.msi and select the installation option for "Open here" context menu item in Windows Explorer.

Expected behavior

If the "Open here" context menu item option is selected during installation it should add a single item for "Open here" and a single item for "Open here as Administrator" to the "PowerShell 6-Preview" context menu in Windows Explorer.

Conversely, if the "Open here" context menu item option is not selected during installation, it should remove any existing context menu for "PowerShell 6-Preview" from Windows Explorer.

Uninstalling the program should also remove the "PowerShell 6-Preview" context menu from the Registry.

Actual behavior

The installation creates two "Open here" context menu items.
Uninstalling the program does not remove the context menu.

Environment data

The following is from PowerShell 6.1.1 because PowerShell 6.2.0-Preview.2 will not launch:

PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.1
PSEdition                      Core
GitCommitId                    6.1.1
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[najeebanwer]

Another problem, the "Open here as Administrator" menu item does not appear to show startup text for PowerShell or show the text "Administrator:" in the Window title.

[bergmeister]

I have seen this happening before with a previous preview of 6.1 that did not correctly clean up on uninstall. This issue is not specific to 6.2-preview2 as this did not happen for me when I upgraded from 6.2-preview1 to 6.2-preview2. You can manually remove the old left over registry keys in

• HKEY_CLASSES_ROOT\Directory\ContextMenus\
• HKEY_CLASSES_ROOT\Directory\Background\shell\
• HKEY_CLASSES_ROOT\Directory\shell\
• HKEY_CLASSES_ROOT\DesktopBackground\shell\
• HKEY_CLASSES_ROOT\Drive\shell\
• HKEY_CLASSES_ROOT\LibraryFolder\background\shell\

[iSazonov]

Should we add this cleanup to msi?

[najeebanwer]

The problem with the duplicate entry is at HKEY_CLASSES_ROOT\Directory\ContextMenus\. The "openpwsh" key is redundant.

[najeebanwer]

The issue with the "Open here as Administrator" menu item is that it adds the following to the HKEY_CLASSES_ROOT\Directory\ContextMenus\PowerShell6-previewx64\shell\runas\command registry entry:
-Command "$host.UI.RawUI.WindowTitle = 'PowerShell 6-preview (x64)'"
I think this is meant to make the window title look nicer, but it actually has less utility than the default window title because a) executing the command causes the window to be cleared and b) the text "Administrator:" no longer appears in the window title which is a good visual clue that the shell is running with elevated privileges

[SteveL-MSFT]

Seems like along the way we renamed that key from open to openpwsh and when it doesn't get cleaned up; it results in duplicate. Seems like we should explicitly remove the old key during setup.

As for the title, the simplest solution is to remove the -Command to update the title which would bring back the startup text (as -Command causes it to be suppressed) and when elevated the Administrator: prefix doesn't get overwritten. The downside is you get the path to exe which doesn't seem horrible to me. Otherwise we'd have to add more to -Command to know when it's elevated to add the prefix as well as enable the startup info to show with -Command which is more code to change. My preference is to just go with reverting the -Command parameter from the command line.

[DarwinJS]

If component codes are being managed properly, then this should not happen.

In general, if an MSI "inplace upgrade over" a previous MSI product does unexpected things that are resolved by uninstall / clean new install - it is because MSI Component GUIDs are not being properly managed across package releases. Basically, they aren't being kept the same across packages as per MSI rules. The MSI Component is actually the most durable identity in MSI because the same exact binary with the same version should have the same component GUID across all MSI packages (including "MSI major upgrades") and across all time. In the case of shared runtimes, MSI Merge modules were intended to keep component GUIDs matching across all vendors shipping shared runtimes.

This is how Microsoft office used to manage 1.5 GB of code and have sensible upgrades all the time.

First, these context menu associations should be in the same component as the exe they point to.

Second, the MSI component code for that EXE should stay the same for major versions of the EXE across packages.

Third, Keypaths should not change between minor MSI package version upgrades. Keypaths for a component include registry keys and file system paths when those components have that as their key path. However, If this component was structured properly, the binary file path would be the keypath and then I believe the registry path of the association should be able to vary.

Windows installer deals with "MSI Components" as the fundamental unit of installation - an entire component is installed, uninstalled, self-healed and upgraded as a unit. Components whose IDs stay the same, but the version changes, should automatically not leave junk over.

Components based on EXE keypaths should take their version number from the binary version of the EXE - which also assumes it is appropriately managed according to MSI rules (which don't really differ from normal major, minor, build rules).

When I used to teach windows installer I had an exercise to emphasize this point. In the exercise, because component codes for identical items did NOT match across major upgrade packages, after an upgrade the only file left on the system was one that was ONLY in the new package. Because component ref counts didn't match for the exact same files across two packages.

[bergmeister]

I tested the upgrade scenarios here using locally built installer versions and think:
The nature of previews is that they might be a bit 'dirty' at times. As far as I see an old preview of 6.1 is causing that, therefore this should not bother us too much. However, when it comes to RTM releases, Microsoft must go through some manual test cases to ensure everything is fine since there were substantial changes to the installer during 6,1 that could possibly cause this to happen for the 6.1->6.2 upgrade. Unfortunately this scenario is very hard to test/reproduce locally now, I would need to extract the original product id guid for simulating a more realistic upgrade scenario and then my locally built installers would probably still be different to an actual release.

[najeebanwer]

Just a note to say that both problems reported here still exist in PowerShell-6.2.0-preview.3-win-x64

1. Duplicate "Open here" context menu item in Windows Explorer
2. The "Open here as Administrator" context menu item clears the command window and removes the word "Administrator" from the window title.