The ProcessPath on Windows could really be any case as it depends on what was provided as the first argv in the lpCommandLine argument to CreateProcess. Seems like we would want this to be OrdinalIgnoreCase on Windows.

Environment.ProcessPath return real file name from file system.

My screenshot shows you that's not the case. The -CommandLine argument there maps directly to the lpCommandLine used when calling CreateProcess. Note the change in capitalisation for P in pwsh.exe changes based on what was provided.

Most tools will probably normalize it but you can't guarantee it'll always match the FS on Windows as anything can call CreateProcess how they like.

Good catch. I will submit a follow-up PR to correct the comparison on Windows.

This seems a bit unwise to hardcode a lot of these checks to specific publishers and paths. Not only does this stop someone from packaging their own MSIX of their PowerShell fork without changing this code it also stops you from installing the MSIX package into a custom volume. Granted the latter still surfaces as being run under C:\Program Files\WindowsApps\...\pwsh.exe through the use of junction points but who knows if that will change at any future date. Also who knows if Windows will change up anything about this application directory.

Wouldn't a better idea to instead see if you can call GetCurrentPackageFamilyName to see if 1 the package has a package identity associated with it (is an MSIX package) and also get the family name for the later psExeHome check.

For example take this pwsh script as a POC

$APPMODEL_ERROR_NO_PACKAGE = 15700

$k32 = New-CtypesLib Kernel32.dll
$l = 0
$b = [Text.StringBuilder]::new()

$res = $k32.CharSet('Unicode').GetCurrentPackageFamilyName([ref]$l, $b)
if ($res -eq $APPMODEL_ERROR_NO_PACKAGE) {
    "PSHome = $PSHome"
}
else {
    $null = $b.EnsureCapacity($l)
    $null = $k32.GetCurrentPackageFamilyName([ref]$l, $b)
    $familyId = $b.ToString()
    "PSHome = $env:LocalAppData\Microsoft\WindowsApps\$familyId"
}

Yeah, I had the same question, but they clearly aren’t keen on supporting any alternative distributors in any form.

About "installing the MSIX package into a custom volume", Ilya (@iSazonov) and I had this discussion in #27782 (comment), and I don't find a way to install the MSIX PowerShell to a different drive.

Wouldn't a better idea to instead see if you can call GetCurrentPackageFamilyName

The idea to do it with the path check was to:

1. Avoid having the code to handle this API not being available on editions like Server Core (Appx/MSIX packages not supported).
2. Avoid a PInvoke at startup.

If it turns out the path check is not sufficient, we can always get back to the GetCurrentPackageFamilyName API call.

and I don't find a way to install the MSIX PowerShell to a different drive.

It's certainly possible but luckily when I tested it, Windows goes to some lengths to pretend it's still under C:\Program Files\WindowsApps through the use of junction points and a lot of the metadata still report the C:\Program Files\WindowsApps location. I still don't think it's a good idea because this seems more like an implementation detail and could potentially change in the future or have some unknown permutation that changes how it works.

If you are interested, you can install an msix package to another volume by using the -Volume parameter in Add-AppxPackage or by using Set-AppxDefaultVolume to change the default volume a package is installed to.

For example I have an msixbundle of 7.6.6 and a separate volume D:\ which I just mounted from a vhdx. I ran the following to setup PowerShell on that volume

Add-AppxVolume -Path D:
Add-AppxPackage -Path .\Downloads\PowerShell-7.6.6.msixbundle -Volume D:

Once installed the package metadata still points to C:\Program Files\WindowsApps and running the process still pretends it's in that directory like I mentioned above but you can see that it's actually a junction point to your custom volume

The idea to do it with the path check was to ...

I can see the concerns around startup time, I have not measured the cost of calling GetCurrentPackageFamilyName and a path check is technically simpler. It just seems wrong to rely on something that may possibly be an implementation detail. Probably a better question for Howard Kapustein (@DrusTheAxe) as to whether this is something that can be relied upon or if there is another alternative.

Thank you Jordan Borean (@jborean93) for going extra mile to try installing the MSIX package to a different volume.

Copilot couldn't find current Microsoft documentation that explicitly promises, as a public contract, that a package installed to a secondary AppX volume will always have InstallLocation represented as a junction beneath C:\Program Files\WindowsApps.

So, I guess I just have to get back to the GetCurrentPackageFamilyName API.