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:
I can install the app in PWSH 7
Install.ps1
breaks because there is no powershell.exe
in $PSHome
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
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. 馃檪
linking dev community ticket: https://developercommunity.visualstudio.com/content/problem/1041840/generated-app-package-does-not-install-inside-pwsh.html
Developer Community for Visual Studio Product family
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 calledpowershell.exe
from thePATH
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 usepowershell.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.