Follow on from dotnet/sdk#30361
I'm not sure why we keep hitting this or what specifically triggers it, as it doesn't happen 100% of the time, but it does seem specific to extra sub-process spawning of dotnet that slngen itself does that causes our build to fail due to not resolving the SDK properly.
Logs from our CI process for linux and windows:
corehost-logs.zip
corehost-linux-logs.zip
We can see from the logs the standard dotnet resolution from other tools and usage works fine, but the extra slngen one done adds extra info to the search path, this is clear on Windows where it's the actual executable embedded in the path:
--- Resolving SDK information from global.json [D:\a\Labs-Windows\Labs-Windows\global.json]
Value 'sdk/allowPrerelease' is missing or null in [D:\a\Labs-Windows\Labs-Windows\global.json]
Resolving SDKs with version = '6.0.405', rollForward = 'latestFeature', allowPrerelease = true
Searching for SDK versions in [C:\Program Files\dotnet\dotnet.exe\sdk]
A compatible .NET SDK was not found.
Following the linked source from @jeffkl's comments in the original issue, we can see as he mentioned that the dotnet executable is searched for here:
|
if (!Utility.TryFindOnPath(environmentProvider, Utility.RunningOnWindows ? "dotnet.exe" : "dotnet", null, out FileInfo dotnetFileInfo)) |
|
if (!DotNetCoreSdkResolver.TryResolveDotNetCoreSdk(environmentProvider, dotnetFileInfo, out DirectoryInfo dotnetCoreSdkDirectoryInfo)) |
However, here that filename is being passed into the directory argument here, it should probably just be the dotnetFileInfo.DirectoryName value of the FileInfo object instead?
|
ResolveSdk(environmentProvider, dotnetFileInfo.FullName); |
|
private static (string sdkDirectory, string globalJsonPath) ResolveSdk(IEnvironmentProvider environmentProvider, string dotnetExeDirectory) |
As then this is passed directly as the directory argument to the PInvokes to hostfxr_resolve_sdk2 here:
|
if (Utility.RunningOnWindows) |
|
{ |
|
Windows.ResolveSdk(dotnetExeDirectory, environmentProvider.CurrentDirectory, 0 /* None */, HandleResolveSdkResult); |
|
} |
|
else |
|
{ |
|
Unix.ResolveSdk(dotnetExeDirectory, environmentProvider.CurrentDirectory, 0 /* None */, HandleResolveSdkResult); |
|
} |
Follow on from dotnet/sdk#30361
I'm not sure why we keep hitting this or what specifically triggers it, as it doesn't happen 100% of the time, but it does seem specific to extra sub-process spawning of
dotnetthat slngen itself does that causes our build to fail due to not resolving the SDK properly.Logs from our CI process for linux and windows:
corehost-logs.zip
corehost-linux-logs.zip
We can see from the logs the standard
dotnetresolution from other tools and usage works fine, but the extra slngen one done adds extra info to the search path, this is clear on Windows where it's the actual executable embedded in the path:Following the linked source from @jeffkl's comments in the original issue, we can see as he mentioned that the dotnet executable is searched for here:
slngen/src/Shared/DevelopmentEnvironment.cs
Line 123 in b19739d
slngen/src/Shared/DevelopmentEnvironment.cs
Line 128 in b19739d
However, here that filename is being passed into the directory argument here, it should probably just be the
dotnetFileInfo.DirectoryNamevalue of theFileInfoobject instead?slngen/src/Shared/DotNetCoreSdkResolver.cs
Line 122 in b19739d
slngen/src/Shared/DotNetCoreSdkResolver.cs
Line 129 in b19739d
As then this is passed directly as the
directoryargument to the PInvokes tohostfxr_resolve_sdk2here:slngen/src/Shared/DotNetCoreSdkResolver.cs
Lines 148 to 155 in b19739d