[environment]::GetCommandLineArgs() from pwsh.exe returns C:\Program Files\PowerShell\6\pwsh.dll instead of C:\Program Files\PowerShell\6\pwsh.exe
PS >[environment]::GetCommandLineArgs()
C:\Program Files\PowerShell\6\pwsh.exe
#6.2.0
C:\Program Files\PowerShell\6\pwsh.dll -WorkingDirectory ~
#5.1
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Name Value
---- -----
PSVersion 6.2.0
PSEdition Core
GitCommitId 6.2.0
OS Microsoft Windows 10.0.18875
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0螕脟陋}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
The behavior is certainly surprising, but I suspect that this is outside of PowerShell's control and currently applies to all .NET Core applications.
it applies to all .net core apps : self-contained application exe.
It's for cross-plateform scenarios with n wrappers with 1 entrypoint dll.
@fmichaleczek: Yes, but just to be clear: it is a _bug_ that applies to all .NET Core apps.
If I'm asking for the _command line_ [arguments], I'm not interested in _implementation details_ such as a DLL being called behind the scenes.
Clearly, the executable specified _on the command line_ is pwsh on Unix-like platforms, and pwsh.exe on Windows - and that's what the APIs should reflect.
@mklement0 sure it's a bug.
This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.
Can this issue be reopened ?
/cc @iSazonov
@mklement0 There is an improvement to Native Hosting scenario on .net core 3.0 Preview 6.
I don't know if there is any plan to move on native hosting later, but it should help if dotnet/coreclr#20562 isn't resolved.
Source :
@fMichaleczek It is Core issue and it is tracked in https://github.com/dotnet/coreclr/issues/20562 - please vote there. I don't think that we will implement native host in PowerShell repo.
Most helpful comment
@mklement0 sure it's a bug.