Powershell: Can't install app packages in PWSH 7

Created on 20 May 2020  路  8Comments  路  Source: PowerShell/PowerShell

Steps to reproduce

Create an app package in Visual Studio (e.g. build a UWP app, Publish app package)
Then in powershell 7, run the generated install.ps1
The script expects there to be a powershell.exe in the $PSHome directory:

image

Expected behavior

I can install the app in PWSH 7

Actual behavior

Install.ps1 breaks because there is no powershell.exe in $PSHome

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.1
PSEdition                      Core
GitCommitId                    7.0.1
OS                             Microsoft Windows 10.0.19631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0鈥
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
```none

Issue-Question Resolution-Answered

Most helpful comment

Not possible, I'm afraid. This was discussed way back before the initial 6.0 release and the pwsh.exe name has been kept since.

There are many applications that may be reliant on powershell.exe being specifically Windows PowerShell, and it's for this reason that the name was changed in the first place.

In fact, the only reason this specific script fails is that it's trying to call powershell.exe relative to $PSHome, which as far as I'm aware is not recommended; had they simply called powershell.exe from the PATH as the vast majority of applications do, it would work as-is.

If we added a shim to powershell.exe all the other apps trying to use powershell.exe and expecting Windows PowerShell may end up breaking, including some Windows components expecting Windows builtin modules that may not yet be compatible with powershell 7. The side-by-side install design is deliberate, and for many folks, necessary.

All 8 comments

I don't think the PowerShell team are the ones writing the install scripts for an app package coming out of Visual Studio. You'll most likely have to get the VS folks to update whatever script generator they're using to account for pwsh as well.

@vexx32 The PS team isn't writing the scripts. However the fact that the EXE name change is a break in appcompat, so this should still be addressed by PS by providing a shim/symlink to pwsh that already existing apps can use.

Not possible, I'm afraid. This was discussed way back before the initial 6.0 release and the pwsh.exe name has been kept since.

There are many applications that may be reliant on powershell.exe being specifically Windows PowerShell, and it's for this reason that the name was changed in the first place.

In fact, the only reason this specific script fails is that it's trying to call powershell.exe relative to $PSHome, which as far as I'm aware is not recommended; had they simply called powershell.exe from the PATH as the vast majority of applications do, it would work as-is.

If we added a shim to powershell.exe all the other apps trying to use powershell.exe and expecting Windows PowerShell may end up breaking, including some Windows components expecting Windows builtin modules that may not yet be compatible with powershell 7. The side-by-side install design is deliberate, and for many folks, necessary.

If VS generates the script you should send the feedback to VS team.

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

I'm the owner of this script, and I'm planning to instead get the PowerShell.exe path using "(Get-Process -Id $PID).Path". This works with PS7 and protects against the unlikely case that the powershell path has somehow been removed from %path%. @vexx32 - Do you see any reason why this wouldn't work?

That sounds like a pretty reasonable solution, yeah. Can't think of anything that should fall apart on, really. 馃檪

Was this page helpful?
0 / 5 - 0 ratings