Summary
We should enable MSBuild to be invoked directly as a native executable (MSBuild.exe / MSBuild) instead of through dotnet MSBuild.dll. This will provide
- Better process identification (processes show as "MSBuild" not "dotnet")
- Win32 manifest embedding support (COM interop)
- critical for full support of the .NET TaskHost feature set
- Consistency with Roslyn compilers (
csc, vbc) which already use app hosts
- Simplified invocation model
- no more "if Framework then
MSbuild.exe else dotnet.exe msbuild.dll"-style logic in the codebase
Background and Motivation
See #12857 for a full treatment of the motivation, but the gist is we'll be more understandable to users, we'll unblock key modernization features, and consuming MSBuild will get simpler overall.
Proposed Feature
See #12857 for a full treatment.
Alternative Designs
No response
Summary
We should enable MSBuild to be invoked directly as a native executable (
MSBuild.exe/MSBuild) instead of throughdotnet MSBuild.dll. This will providecsc,vbc) which already use app hostsMSbuild.exeelsedotnet.exe msbuild.dll"-style logic in the codebaseBackground and Motivation
See #12857 for a full treatment of the motivation, but the gist is we'll be more understandable to users, we'll unblock key modernization features, and consuming MSBuild will get simpler overall.
Proposed Feature
See #12857 for a full treatment.
Alternative Designs
No response