dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.65k stars 1.06k forks source link

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

Open Pollyfun opened 4 months ago

Pollyfun commented 4 months ago

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[bot] commented 4 months ago

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

Pollyfun commented 4 months ago

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

baronfel commented 4 months ago

--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 commented 3 months ago

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!