API-using application is spawned instead of `dotnet` when using CodeTaskFactory

I’m trying to open csproj files via Microsoft.CodeAnalysis.MSBuild.MSBuildWorkspace.OpenProjectAsync from my console app. One of the projects, a rather big one, hangs the execution and spawns another instance of the app.

Tried both v4.6.0 from nuget.org and built myself from https://github.com/dotnet/roslyn/releases/tag/Visual-Studio-2022-Version-17.6.4, same behavior.

Tried to debug but quickly got lost… My best guess is that MSBuild is trying to create additional processes (for compilation?) to parallelize since it’s a large project, but instead instantiates my app. Any suggestions much appreciated.

[GangWang01]

Attached a sample ReproSample.zip to repro this issue.

For .NET version of msbuild, root cause is the following code couldn’t set dotnet cli path correctly when running the application via application.exe. Rather than the path of dotnet.exe, it’s wrongly set using the path of the applicaiton. https://github.com/dotnet/msbuild/blob/3050e91563b2b9bbafd820f4e8cd3d050dd9d21a/src/Tasks/RoslynCodeTaskFactory/RoslynCodeTaskFactoryCompilers.cs#L16-L18 For the repro sample, the fix is to modify dotnet cli path based on the environment variable MSBUILD_EXE_PATH that is set when registering the .NET SDK instance. But Roman mentioned getting dotnet cli path from the environment variable is not reliable and may not work for all scenarios, like Visual Studio doesn’t need to register the instance (Cc @rokonec, please correct me if anything wrong). Welcome suggestions on a good way to get dotnet cli path working for all scenarios.

As for .NET framework version of msbuild, the System.MissingMethodException with the meesage Method not found: ‘System.ReadOnlySpan1<Char> Microsoft.IO.Path.GetFileName(System.ReadOnlySpan1<Char>)’ is thrown out from https://github.com/dotnet/msbuild/blob/ec8b4a4eddeef899e427c77e4744f9fdb15fe3e8/src/Shared/FileMatcher.cs#L1650-L1651. This is related to https://github.com/dotnet/msbuild/issues/7873.

[Leon99]

Running it using dotnet application.dll helps, thanks for the workaround and the explanation @rainersigwald!