--nodereuse:false not closing all dotnet.exe processes after build or publish

[Pollyfun]

Description

After running dotnet build/publish with the --nodereuse:false flag, one dotnet.exe process still remains in memory.

Reproduction Steps

dotnet new console -n Console1
dotnet build Console1/Console1.csproj --nodereuse:false

Expected behavior

For all the dotnet.exe processes (started by these commands) to shut down afterwards.

Actual behavior

one dotnet.exe process remains active

Regression?

No response

Known Workarounds

Also adding the UseSharedCompilation parameter always close down dotnet.exe processes.

dotnet new console -n Console1
dotnet build Console1/Console1.csproj --nodereuse:false -p:UseSharedCompilation=false

Configuration

.NET SDK 8.0.205 Commit 3e1383b780
Windows 10 Pro 22H2 19045.4412
x64

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-console
See info in area-owners.md if you want to be subscribed.

[Pollyfun]

After more testing it seems dotnet build works as expected on some machines (not mine though). But dotnet publish consistently has this issue.

[baronfel]

--nodereuse is an MSBuild-engine-specific flag, UseSharedCompilation is a property that other build servers like Roslyn/Razor use to determine if they should shut down. However, if you want to prevent the use of any of the build servers at all, I'd suggest just using the --disable-build-servers flag - it is intended to be easier to use so you don't have to specify all of those flags.

Why is it a problem if the build servers remain around after a build? Part of the performance benefit of using them is predicated on not starting new processes all the time. If you want to use the servers during a build (highly recommended!) and remove them afterwards, consider dotnet build-server shutdown.

[Pollyfun]

The reason we need to make sure that dotnet.exe is shut down after usage, is that our application contains the SDK in a subfolder (to give exact control over which version is used and not having Windows update interfere). The application calls dotnet.exe for build/publish etc. But dotnet.exe cannot be allowed to continue running after the application is shut down, since dotnet.exe will be locked if the user tries to uninstall or upgrade the application from this state.

Anyway, I've done tests with the --disable-build-servers flag and it has consistently worked.
Thanks for the quick feedback!