Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mklement0 opened this issue Apr 26, 2018 · 2 comments

Comments

@mklement0
Copy link

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
Copy link
Member

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
Copy link
Member

Assuming 3.0 for now pending prototype

@msftgits msftgits transferred this issue from dotnet/core-setup Jan 30, 2020
@msftgits msftgits added this to the Future milestone Jan 30, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@jeffschwMSFT jeffschwMSFT removed the untriaged New issue has not been triaged by the area owner label Feb 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

5 participants