Support calling .NET Core-compiled custom executables by symlinks on Windows via the GetFinalPathNameByHandle WinAPI function

[mklement0]

Note: This is a follow-up from #2923, which was closed before suggesting use of the GetFinalPathNameByHandle Windows API function as a possible solution.

Given that 2.1 will support a way to approximate the functionality - see https://github.com/dotnet/core-setup/issues/3260#issuecomment-375780087 - the need to support symlinks directly is perhaps less pressing, but I think it's still worth considering; to recap from the original issue:

The idea is to use a symlink to provide an efficient, shell-agnostic way to invoke an executable by a different name (without having to resort to shell-specific aliases or cumbersome wrapper batch files) - just like on Unix platforms, where this scenario is already supported.

There is renewed interest in this ability based on the recent decision by @powershell-committee to provide a pwsh-np executable as an alias of the PowerShell Core pwsh executable to indicate the desire to suppress loading of the PowerShell user profile - see PowerShell/PowerShell#992 (comment)

As for a possible implementation:

Note: I have not really delved into this - the first question to answer is whether there is a fundamental willingness to solve this problem.

• It sounds like argv[0] reports the symlink's path.

• A call to GetFinalPathNameByHandle should provide the symlink's target, which can then be called instead.

[steveharter]

Since 2.1 is in RC, this will not make it in unless we have a pressing scenario, so moving to Future.

The suggestion of GetFinalPathNameByHandle should work. Thanks.

[steveharter]

Assuming 3.0 for now pending prototype

[elinor-fung]

@agocke you addressed this with #99576, right?

[agocke]

Yup this is fixed now.