-
Improvement
-
Resolution: Fixed
-
Major
-
None
When the plugin detects "not Unix" it will try to start powershell.exe. On Windows Nano Server there is only PowerShell Core available and the executable name there is pwsh.exe. Creating a hardlink or symlink named powershell.exe that links to pwsh.exe does not work because when you run powershell.exe (the link) the process exits with the message:
The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.
This makes it currently impossible to use PS Core on Nano Server.
One simple solution would be to detect Nano Server and then just run pwsh.exe like on Unix systems.
When running Windows Server Core this gets a little more complicated because you can have both the regular PS and PS Core side by side, so a decision must be made about the behavior in this case.
The options are:
- If pwsh.exe is in PATH then always prefer it over the regular one
- If regular powershell.exe is available then always prefer it over PS Core
The first option makes the most sense to me because having both PS versions is not likely to happen and if you have them running side by side that's probably because you want PS Core to be used (if you want regular PS then just don't install PS Core in the first place).
- is related to
-
JENKINS-49443 PowerShell Core has renamed the binary from powershell to pwsh
-
- Open
-
[JENKINS-52421] Support PowerShell Core on Windows-Systems
Stan Wijckmans
created issue -
Stan Wijckmans
made changes -
| Summary | Original: Support PowersShell Core on NanoServer | New: Support PowersShell Core on Nano Server |
Stan Wijckmans
made changes -
| Summary | Original: Support PowersShell Core on Nano Server | New: Support PowerShell Core on Nano Server |
Stan Wijckmans
made changes -
| Description |
Original:
When the plugin detects "not unix" it will try to start powershell.exe. On Windows Nano Server there is only PowerShell Core available and the executable name there is pwsh.exe. Creating a hardlink or symlink named powershell.exe that links to pwsh.exe does not work because when you run powershell.exe (the link) the process exits with the message: The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'. A fatal error was encountered. This executable was not bound to load a managed DLL. This makes it currently impossible to use PS Core on Nano Server. One simple solution would be to detect Nano Server and then just run pwsh.exe lust like on unix systems. When running Windows Server Core this gets a little more complicated because you can have both the regular PS and PS Core side by side, so a decision must be made about the behavior in this case. The options are: * If pwsh.exe is in PATH then always prefer it over the regular one * If regular powershell.exe is available then always prefer it over PS Core The first option makes the most sense to me because having both PS versions is not likely to happen and if you have them running side by side that's probably because you want PS Core to be used (if you want regular PS then just don't install PS Core in the first place). |
New:
When the plugin detects "not unix" it will try to start powershell.exe. On Windows Nano Server there is only PowerShell Core available and the executable name there is pwsh.exe. Creating a hardlink or symlink named powershell.exe that links to pwsh.exe does not work because when you run powershell.exe (the link) the process exits with the message: {{The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.}} {{ A fatal error was encountered. This executable was not bound to load a managed DLL.}} This makes it currently impossible to use PS Core on Nano Server. One simple solution would be to detect Nano Server and then just run pwsh.exe lust like on unix systems. When running Windows Server Core this gets a little more complicated because you can have both the regular PS and PS Core side by side, so a decision must be made about the behavior in this case. The options are: * If pwsh.exe is in PATH then always prefer it over the regular one * If regular powershell.exe is available then always prefer it over PS Core The first option makes the most sense to me because having both PS versions is not likely to happen and if you have them running side by side that's probably because you want PS Core to be used (if you want regular PS then just don't install PS Core in the first place). |
Stan Wijckmans
made changes -
| Description |
Original:
When the plugin detects "not unix" it will try to start powershell.exe. On Windows Nano Server there is only PowerShell Core available and the executable name there is pwsh.exe. Creating a hardlink or symlink named powershell.exe that links to pwsh.exe does not work because when you run powershell.exe (the link) the process exits with the message: {{The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.}} {{ A fatal error was encountered. This executable was not bound to load a managed DLL.}} This makes it currently impossible to use PS Core on Nano Server. One simple solution would be to detect Nano Server and then just run pwsh.exe lust like on unix systems. When running Windows Server Core this gets a little more complicated because you can have both the regular PS and PS Core side by side, so a decision must be made about the behavior in this case. The options are: * If pwsh.exe is in PATH then always prefer it over the regular one * If regular powershell.exe is available then always prefer it over PS Core The first option makes the most sense to me because having both PS versions is not likely to happen and if you have them running side by side that's probably because you want PS Core to be used (if you want regular PS then just don't install PS Core in the first place). |
New:
When the plugin detects "not unix" it will try to start powershell.exe. On Windows Nano Server there is only PowerShell Core available and the executable name there is pwsh.exe. Creating a hardlink or symlink named powershell.exe that links to pwsh.exe does not work because when you run powershell.exe (the link) the process exits with the message: {quote}{{The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.}} A fatal error was encountered. This executable was not bound to load a managed DLL. {quote} This makes it currently impossible to use PS Core on Nano Server. One simple solution would be to detect Nano Server and then just run pwsh.exe lust like on unix systems. When running Windows Server Core this gets a little more complicated because you can have both the regular PS and PS Core side by side, so a decision must be made about the behavior in this case. The options are: * If pwsh.exe is in PATH then always prefer it over the regular one * If regular powershell.exe is available then always prefer it over PS Core The first option makes the most sense to me because having both PS versions is not likely to happen and if you have them running side by side that's probably because you want PS Core to be used (if you want regular PS then just don't install PS Core in the first place). |
Stan Wijckmans
made changes -
| Description |
Original:
When the plugin detects "not unix" it will try to start powershell.exe. On Windows Nano Server there is only PowerShell Core available and the executable name there is pwsh.exe. Creating a hardlink or symlink named powershell.exe that links to pwsh.exe does not work because when you run powershell.exe (the link) the process exits with the message: {quote}{{The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.}} A fatal error was encountered. This executable was not bound to load a managed DLL. {quote} This makes it currently impossible to use PS Core on Nano Server. One simple solution would be to detect Nano Server and then just run pwsh.exe lust like on unix systems. When running Windows Server Core this gets a little more complicated because you can have both the regular PS and PS Core side by side, so a decision must be made about the behavior in this case. The options are: * If pwsh.exe is in PATH then always prefer it over the regular one * If regular powershell.exe is available then always prefer it over PS Core The first option makes the most sense to me because having both PS versions is not likely to happen and if you have them running side by side that's probably because you want PS Core to be used (if you want regular PS then just don't install PS Core in the first place). |
New:
When the plugin detects "not Unix" it will try to start powershell.exe. On Windows Nano Server there is only PowerShell Core available and the executable name there is pwsh.exe. Creating a hardlink or symlink named powershell.exe that links to pwsh.exe does not work because when you run powershell.exe (the link) the process exits with the message: {quote}{{The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.}} A fatal error was encountered. This executable was not bound to load a managed DLL. {quote} This makes it currently impossible to use PS Core on Nano Server. One simple solution would be to detect Nano Server and then just run pwsh.exe like on Unix systems. When running Windows Server Core this gets a little more complicated because you can have both the regular PS and PS Core side by side, so a decision must be made about the behavior in this case. The options are: * If pwsh.exe is in PATH then always prefer it over the regular one * If regular powershell.exe is available then always prefer it over PS Core The first option makes the most sense to me because having both PS versions is not likely to happen and if you have them running side by side that's probably because you want PS Core to be used (if you want regular PS then just don't install PS Core in the first place). |
esra
made changes -
| Component/s | New: powershell-plugin [ 16044 ] |
Martin Bauer
made changes -
| Priority | Original: Minor [ 4 ] | New: Major [ 3 ] |
Martin Bauer
added a comment - The problem is a general one on Windows platforms.
Currently it is not possible to use Powershell Core (currently version 6 and 7) with the Jenkins plugin on Windows machines.
The version 5.1 (integrated in Windows) is always used. But this version is no longer developed and scripts may require newer versions of PS.
There should be a possibility to use pwsh instead of powershell on Windows systems.
The best would be to have two Build-Steps provided from the Plug-in on Windows Systems:
Powershell
and Powershell Core
Martin Bauer
added a comment - The problem is a general one on Windows platforms.
Currently it is not possible to use Powershell Core (currently version 6 and 7) with the Jenkins plugin on Windows machines.
The version 5.1 (integrated in Windows) is always used. But this version is no longer developed and scripts may require newer versions of PS.
There should be a possibility to use pwsh instead of powershell on Windows systems.
The best would be to have two Build-Steps provided from the Plug-in on Windows Systems:
Powershell
and Powershell Core
Are there any updates on this?