Need to get the path to the `dotnet.exe` host in GetRunInformation MSBuild target
See original GitHub issueWe are currently returning dotnet.exe
without a path in <Target Name="GenerateRunInformation">
in the Microsoft.DotNet.Core.Sdk.targets file.
We should either:
- Figure out a way to get to the correct
dotnet.exe
to call from inside our MSBuild target. - Or pass back some sort of indicator to
dotnet run
that this project should use its host to run the project.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:10 (9 by maintainers)
Top Results From Across the Web
How can I specify path of msbuild when running "dotnet ...
However, I want to be able to specify the exact path to msbuild like: dotnet C:\name\msbuild.exe. (Adding it to the path is not...
Read more >dotnet build command - .NET CLI
The dotnet build command builds a project and all of its dependencies.
Read more >dotnet msbuild command - .NET CLI
The dotnet msbuild command allows access to a fully functional MSBuild. The command has the exact same capabilities as the existing MSBuild ......
Read more >Visual Studio 2019 unable to locate .Net Core SDK
Find the path to dotnet.exe manually (usually C:\Program Files\dotnet ) and add it to PATH. Check in Control Panel whether there is a...
Read more >.NET | TeamCity On-Premises Documentation
To ensure that a specific version of native MSBuild is used (for example, in a Docker container), you need to set the path...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
One concern is when MSBuild is running on the desktop framework, but building a .NET Core App. Say, for example, when invoked from VS.
Reopening as there’s still a TODO in the sdk that points to this tracking issue: https://github.com/dotnet/sdk/blob/3ed908ee77c592bae787ac78f466c3bc0581970a/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L728