Powershell: Is it possible to test for the availability of other PowerShell versions on Windows

[swinster]

Ability to test for alternative PowerShell versions

With PowerShell core, many CmdLets perform better than those available in Windows PowerShell (e.g. Invoke-RestMethod). In the past, I have run a simple test to see if an exe (on a Windows system) was available at a given path, but with the ability to install PS Core as an App (using the MSXI), I'm no longer sure how I can test for this. For example, if a script was run using PS 5.1, and PS Core v7 was available, then I might wish to run my script in that environment for better performance.

This may already be available, however I couldn't find a simple way to check in all possible cases.

[anmenaga]

Looks like both MSI and MSIX PS Core v7 packages (by default) add path to pwsh.exe to system-wide PATH environment variable, so it should be possible to attempt to start pwsh.exe (without specifying path) and if it fails then fall back to using PS 5.1 / %WinDir%\System32\WindowsPowerShell\v1.0\powershell.exe.
Though this won't start the latest/newest pwsh.exe if multiple versions are installed.

@rjmholt , how does VS Code extension solve this, when it needs to find the latest PS Core installed?

[rjmholt]

The PowerShell extension looks for known places where PowerShell might be installed.

We would use the PATH, but that means we need to start PowerShell to find out what version it is. Whereas, well-known installation locations correspond to particular versions.

[iSazonov]

Self discovery :-)

Get-Command -CommandType Application pwsh

[rjmholt]

Just to add to my comment before, if you're only on Windows, gcm -Type Application pwsh will report the version from the PE metadata, meaning you can reliably determine the version of PowerShell without starting it (the same is true of powershell.exe).

But executable formats on other platforms have no such metadata field, so you're out of luck there.

Perhaps PowerShell installations do/should have a simple metadata file that we could use to check such information without incurring the cost of a startup?

[swinster]

@rjmholt and @iSazonov fwiw, here is the output of gcm -Type Application pwsh from PS v5.1 Currently, I only have PSCore v7 rc2 installed using MSXI.

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     pwsh.exe                                           0.0.0.0    C:\Users\me\AppData\Local\Microsoft\...

So, whilst the this seem to show that at least one PSCore instance is install, it don't show the version. Perhaps this is because this is a preview version?

[rjmholt]

It looks like the MSIX doesn't have a verison in it:

> gcm -Type Application pwsh

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     pwsh.exe                                           7.0.0.0    C:\Program Files\PowerShell\7-preview\pw…
Application     pwsh.exe                                           6.2.3.0    C:\Program Files\PowerShell\6\pwsh.exe
Application     pwsh.exe                                           0.0.0.0    C:\Users\rjmho\AppData\Local\Microsoft\W…
Application     pwsh.exe                                           6.2.2.0    C:\Users\rjmho\.dotnet\tools\pwsh.exe

[iSazonov]

It looks like the MSIX doesn't have a verison in it:

Is it a bug? Should we track this in new issue?

Perhaps PowerShell installations do/should have a simple metadata file that we could use to check such information without incurring the cost of a startup?

Is this important for tools?

We could add a versions fields in powershell.config.json.

[DHowett-MSFT]

The MSIX looks like it doesn’t have a version in it because pwsh.exe is an app execution alias reparse point. Same problem as the issue (I can’t find it easily from my phone) where PowerShell doesn’t return to the prompt for app execution aliases: it tries to crack the PE file to read something out of it, and it fails because it’s not a normal file at all.

Perhaps worth adding to the existing bug and coming up with a holistic solution. Probably not necessary to file another?

[iSazonov]

@DHowett-MSFT Do you mead #9970 ?

[doctordns]

Self discovery :-)

Get-Command -CommandType Application pwsh

Unfortunately, that does not actually find any of the Daily builds or builds not on the execution path.

[DHowett-MSFT]

@DHowett-MSFT Do you mead #9970 ?

Yep! Thanks!

[rjmholt]

Unfortunately, that does not actually find any of the Daily builds or builds not on the execution path.

Yes, there's no automatic mechanism for that. PowerShell can be installed with xcopy or unzip; there's no registration mechanism. So you can treat the PATH as being the "discoverable" PowerShells and just use that, and/or you can search well known installation paths. But if you really need to find all possible PowerShell installations on a machine, you're going to have to scour the whole directory structure.

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.