Need to get the path to the dotnet.exe host in GetRunInformation MSBuild target

[eerhardt]

We are currently returning dotnet.exe without a path in <Target Name="GenerateRunInformation"> in the Microsoft.DotNet.Core.Sdk.targets file.

We should either:

1. Figure out a way to get to the correct dotnet.exe to call from inside our MSBuild target.
2. Or pass back some sort of indicator to dotnet run that this project should use its host to run the project.

[brthor]

My 0.02c here.

For .NET Core MSBuild, it should use the path to the host it was invoked with. I think the closest we can currently get to this is resolving the path relative to the current shared framework deps file like here:

https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.Cli.Utils/Muxer.cs#L45

[eerhardt]

For .NET Core MSBuild, it should use the path to the host it was invoked with.

One concern is when MSBuild is running on the desktop framework, but building a .NET Core App. Say, for example, when invoked from VS.

[enricosada]

csc roslyn fixed embeeding a .cmd/.sh.
but other target files not bundled with sdk cannot do that, so ihmo is important.

i filled dotnet/msbuild#1669 in msbuild repo, because is not about sdk itself

[tannergooding]

I'm seeing an issue that is possible related:

1. Create a netcore console app
2. Explicitly target x86
3. Attempt to run
4. x64 dotnet is used and dotnet crashes

This is when trying to F5 or F11 from within VS.

[livarcocc]

How are you invoking dotnet run? Is the version of the host that you are using a x86 host? Do you have the x86 host ahead on the PATH compared to the x64 one? dotnet run today simply shell out to the host. So, if you have a x86 project and you have an x64 host in the path (before the x86) you will hit this issue.

[tannergooding]

I just created a netcore console app, set it to target x86 and hit F5 (I have both the x64 and x86 SDK installed). This seems like a scenario that we should have covered, regardless of how the paths are configured.

[livarcocc]

This is something that we have been thinking about but we could not come up with the right solution yet. Strictly speaking, there is no way that we can know which dotnet in PATH is an x86 versus an x64 dotnet. So, this responsibility has been falling on the user.

I agree that if the user invoked <path_to_x86_dotnet>/dotnet run, then it should work, even if the x64 dotnet is ahead on the path, and I don't think that works today because of how we shell out the dotnet invocation. That we could fix if this bug were fixed.

[tannergooding]

Is this not something the SDK itself could expose, in a similar manner to how the SDK's are able to add new target frameworks (i.e. netcore2.0 shows in VS only after you install the 2.0 Preview SDK)? Otherwise, why not check the PE Header Metadata for all dotnet on the path... The first PE32+ version is used for x64 and the first PE32 version is used for x86...

[wli3]

Use linker's example. Use DOTNET_HOST_PATH on core. And use $(NetCoreRoot) with dotnet/dotnet.exe on fullframework. I believe $(NetCoreRoot) property is also available for Razor props and targets (please double check)

https://github.com/dotnet/sdk/blob/46917a9b622ea05377dc438db9f6b6e184bd3d83/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L78-#L94

[ViktorHofer]

Reopening as there's still a TODO in the sdk that points to this tracking issue:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets

Line 728 in 3ed908e

<!-- TODO: https://github.com/dotnet/sdk/issues/20 Need to get the DotNetHost path from MSBuild -->