We have some cert deployment scripts that are designed to run in PowerShell 7.x and can’t be run in PowerShell 5.x. We’d like to be able to select the PowerShell version that the script is run with in the Certify client. These scripts leverage the $result variables, so it’s not as simple as just doing a Run... and specifying the path to pwsh.exe.
Hi, we actually have a port of the core parts of Certify for Linux in the works and we will need PowerShell 7 there as well, so it will happen. In the meantime though I’d suggest as a workaround invoking PS 7 from a wrapper script, so:
param($result)
C:\Program Files\PowerShell\7\pwsh.exe C:\scripts\your-powershell-script.ps1 $result
1 Like
Great! And good idea on the workaround - I never considered just calling it from PS5.
1 Like
Is there work still planned for pwsh 7 support? It would be preferable to the wrapper from an error logging standpoint. I have been logging to txt files as errors in the 7 script don’t bubble up to the CTW logs.
Our powershell runs by hosting it’s own powershell runspace in-process (.net framework 4.6.2+). We do currently have the option to run Powershell tasks in their own process (see under Task Parameters), which starts the system powershell exe, in order of oldest to newest:
"%WINDIR%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"%PROGRAMFILES%\\PowerShell\\7\\pwsh.exe"
Really though any machine is going to have the v1.0 path, so that will always get chosen. We need to give you a preference you can set for the pwsh path.
We are developing a dotnet (core) version of our whole app and service, with a new web UI. The dotnet core version uses the more modern powershell sdk which will in turn give it the equivalent features.
We capture the error stream powershell (5.x) has, so to get them reported as errors via a wrapper you’d need to capture the error stream output somehow and report it as an error in the wrapper, so not ideal.