CurrentHost was not properly set when DisableInProcNode = false

[xen2]

Fixes #6782
Follow-up of #6890

Context

Tried DisableInProcNode = false and couldn't make it work.
After some investigations, it turns out the code in NodeProviderOutOfProcBase.GetCurrentHost() has some issues:

msbuild/src/Build/BackEnd/Components/Communications/NodeProviderOutOfProcBase.cs

Line 593 in 24b3318

string dotnetExe = Path.Combine(FileUtilities.GetFolderAbove(BuildEnvironmentHelper.Instance.CurrentMSBuildExePath, 2),

In my case, CurrentMSBuildToolsDirectory returns C:\Program Files\dotnet\sdk\6.0.100\MSBuild.dll.
FileUtilities.GetFolderAbove() 2 levels makes it try to resolve dotnet.exe from C:\Program Files\dotnet\sdk\dotnet.exe instead of C:\Program Files\dotnet\dotnet.exe.
I believe this is because the filename itself was not taken into account (it counts as 1 extra step for FileUtilities.GetFolderAbove())

Changes Made

Used CurrentMSBuildToolsDirectory rather than CurrentMSBuildExePath.
Another option would be to use 3 for FileUtilities.GetFolderAbove, but since the function explicitely contains "folder" in its name, I preferred to avoid the case where it is later changed to ignore the top-level file rather than considering it as a folder.

Testing

I tested with a simple console app.
(Note: without being careful it could quickly crash the PC as mentioned in #6782 because it calls itself in infinite loop (instead of dotnet.exe), unless you add some check on args.Length as done in this test code)

using Microsoft.Build.Execution;
using Microsoft.Build.Locator;

// Avoid infinite loop => system crash (until MSBuild bug to properly resolve dotnet.exe is fixed)
if (args.Length > 0) return;

var projectPath = @"C:\dev\ConsoleApp8\ConsoleApp8.csproj";

MSBuildLocator.RegisterDefaults();
RunTest();

void RunTest()
{
    var mainBuildManager = new BuildManager();
    var pc = new Microsoft.Build.Evaluation.ProjectCollection();
    var parameters = new BuildParameters(pc) { DisableInProcNode = true };

    // Run a MSBuild /t:Restore <projectfile>
    var request = new BuildRequestData(projectPath, new Dictionary<string, string>(), null, new[] { "Restore" }, null, BuildRequestDataFlags.None);
    mainBuildManager.Build(parameters, request);
}

Notes

[Forgind]

Thanks 😅

I remember having looked at this in a debugger to see how many folders up, but I assumed it would be constant.

I was going to ask about bitness, but I think this should always be 64-bit, so it isn't an issue.

[Forgind]

Actually, I looked again, and I have a dotnet.exe in both dotnet and sdk. I'm not sure which is "standard;" I should probably make sure it's expected in dotnet but not sdk.

[Forgind]

Sounds like it's weird that I have dotnet.exe in sdk, so this looks good. 👍

[xen2]

Actually, I looked again, and I have a dotnet.exe in both dotnet and sdk. I'm not sure which is "standard;" I should probably make sure it's expected in dotnet but not sdk.

Ha, that explains it!
Double-checked on two computers and both of them have it only in dotnet top-level folder, not in sdk.

In that case, feel free to switch to the other approach FileUtilities.GetFolderAbove(BuildEnvironmentHelper.Instance.CurrentMSBuildExePath, 3) rather than FileUtilities.GetFolderAbove(BuildEnvironmentHelper.Instance.CurrentMSBuildToolsDirectory, 2) if you prefer.

[Forgind]

I don't really have a preference between the two, but I can check in our PR review meeting whether anyone else does.

[rainersigwald]

Thanks @xen2!

@Forgind can we update the version check in Locator to keep specifying the environment for 17.0?

I was going to ask about bitness, but I think this should always be 64-bit, so it isn't an issue.

The .NET SDK has a 32-bit x86 version. However, because MSBuild doesn't support cross-processor-architecture task execution on .NET Core, we don't have an amd64 directory and the position of dotnet.exe relative to MSBuild.dll doesn't change in the 32-bit SDK.

[xoofx]

Ran exactly into this bug today, I was going mad! Then I debugged and found also the issue, but found that it was also already fixed here, thank you @xen2! 🤗

[xen2]

Ran exactly into this bug today, I was going mad! Then I debugged and found also the issue, but found that it was also already fixed here, thank you @xen2! 🤗

Small world! ;)
You're welcome!