Consider PATH again when searching for dotnet host #80859
Conversation
|
@333fred @RikkiGibson @dotnet/roslyn-compiler for a second review, thanks. This fixes a regression. |
| internal static string? GetToolDotNetRoot() | ||
| { | ||
| if (GetDotNetHostPath() is { } dotNetHostPath) | ||
| var directoryName = Path.GetDirectoryName(GetDotNetPathOrDefault()); |
There was a problem hiding this comment.
It looks like before we were looking specifically for the directory containing a suitable .NET runtime installation?
But now we are searching the path, and the dotnet we find on the PATH might be linked into a location like /usr/bin/dotnet. Is it fine to just return /usr/bin from this call?
There was a problem hiding this comment.
But now we are searching the path, and the dotnet we find on the PATH might be linked into a location like
/usr/bin/dotnet. Is it fine to just return/usr/binfrom this call?
Good catch, that wouldn't work. I guess we can resolve symlinks first.
| return s; | ||
| } | ||
|
|
||
| private const uint FILE_READ_ATTRIBUTES = 0x0080; |
There was a problem hiding this comment.
Where do these values come from? What documentation can I look at to verify them?
There was a problem hiding this comment.
In win32 API docs for the corresponding functions:
CreateFileW: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew
GetFinalPathNameByHandleW: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlew
| var symlinkPath = Path.Combine(binDir.Path, $"dotnet{PlatformInformation.ExeExtension}"); | ||
|
|
||
| // Create symlink from binDir to the actual dotnet executable | ||
| File.CreateSymbolicLink(path: symlinkPath, pathToTarget: globalDotNetExe.Path); |
There was a problem hiding this comment.
Does this test need to be Windows-only?
There was a problem hiding this comment.
Why? Symlinks are a thing especially on Linux.
| //------------------------------------------------------------------------------ | ||
| extension(File) | ||
| { | ||
| public static FileSystemInfo? ResolveLinkTarget(string path, bool returnFinalTarget) |
There was a problem hiding this comment.
Does this work on Linux/Mac?
There was a problem hiding this comment.
No, but on Linux, we run on .NET Core where the File.ResolveLinkTarget API exists from the BCL. This custom Win32 polyfill is defined only for .NET Framework (which I think we only support on Windows? I'm not sure about Mono, but given the other NativeMethods are also win32 APIs, this seems fine).
4 participants
Fixes dotnet/msbuild#12669. Before the change to use csc apphost, we were searching for
dotnet.exeeither fromDOTNET_HOST_PATHorPATH. With csc apphost (#80026) we regressed this by considering the dotnet host only fromDOTNET_HOST_PATH(and passing that asDOTNET_ROOTto the apphost) - but that variable is not passed in MSBuilds older than 18.x (where the previous non-apphost implementation would work fine since it would fallback to findingdotnet.exeinPATH).