Find dotnet.exe instead of <name>.exe when building out-of-proc using MSBuildLocator

[Forgind]

Fixes #6782

Context

When using MSBuildLocator, the first process you start is named after your app, not dotnet or msbuild, yet it still loads MSBuild assemblies. When it then starts an out-of-proc build on core, it tries to use the current host, which is normally dotnet.exe, but in this case is .exe. MSBuild can't find it to connect, so it assumes it launches another node. It should stop after that, but it just keeps going and makes hundreds or thousands of nodes until your computer crashes. That is bad. This defaults to looking for a nearby dotnet.exe (if you're on core) and uses that instead, falling back to .exe only on failure. This should handle any case in which you find MSBuild in an sdk installation.

Changes Made

Look for a dotnet.exe instead of your current host.

Testing

Broke repro.

Notes

Do not try to reproduce this naively. Your computer will be unhappy.

Also, I suspect this may have been the cause of my 9/10 comment here (internal link).

[rainersigwald]

Would it make sense to push this into GetCurrentHost() so we only have to do the file-exists check once?

[jeffkl]

There is a lot going on in this method:

• On Windows, it uses native methods to launch the process so the path to MSBuild.exe needs to be prepended to the command-line arguments. @rainersigwald do you know why we use a different method to launch the process? The code doesn't seem to need to as far as I can tell. Maybe we can get rid of it?
• For .NET Core, the command-line arguments must be prepended with the the path to MSBuild.dll and the EXE is dotnet.

I see some missing logic in the current implementation:

• On Windows, its dotnet.exe, on non-Windows its just dotnet
• The path to MSBuild.dll is prepended twice on Windows (which technically works but sees dirty)
• GetCurrentHost() is only ever correct if you run dotnet directly so using it as a fallback seems not great

I would do the following:

1. Make a method like GetNodeExe() that has all of the logic to find the path to the executable that represents the node, so MSBuild.exe on .NET Framework, dotnet.exe or dotnet for .NET Core.
2. Make a method like GetNodeArguments() that adjusts the command-line arguments
   Prepend MSBuild.exe on Windows since its using native APIs
   Prepend MSBuild.dll on .NET Core

In my opinion that would simplify this method and make it easier to rationalize what its doing. You could also make these two methods internal and write a unit test to verify they return the correct values.

[Forgind]

As far as falling back to GetCurrentHost, I agree it isn't terribly likely to succeed, but I don't think we have a better option. There's a chance someone has fancy logic in their project to make it work, and if we don't fall back to GetCurrentHost, we would break that.

[rainersigwald]

I'm pretty sure if you don't fall back to current-host our own dogfood builds will fail (they're invoked via dotnet.exe path\to\some\msbuild.dll).

[jeffkl]

GetCurrentHost() is only ever correct if you run dotnet directly so using it as a fallback seems not great

Sorry what I meant was having this method here only to use as a fallback, when the entirety of the logic could live inside of it. I did not mean to get rid of the fallback all together. To have solid logic here that then falls back to a method seems clunky is all.

[jeffkl]

These could be moved into the else block below where its actually used, unless we get rid of the different ways of launching the process in which case this can just go away.