Sdk: Dotnet.exe spawning multiple dotnet instances when running dotnet.exe <application.dll>

[adiaaida]

Steps to reproduce

set UseSharedCompilation=false
Follow instructions in https://github.com/aspnet/JitBench to run MusicStore
Check task manager to see number of dotnet.exe processes.

Expected behavior

Once MusicStore/your application has finished, there should be no zombie dotnet processes hanging around. Setting UseSharedCompilation to false used to get us this behavior but not longer does. This is a problem for our automation when we want to clean up after ourselves.

Actual behavior

There are something like 12 dotnet.exe processes still running in the background

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
Version: 2.2.100-preview1-009013
Commit: 7794eed633

Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\michelm\optimization\output\CLRx64WINmas\IBC\clix64\sdk\2.2.100-preview1-009013\

Host (useful for support):
Version: 2.2.0-preview1-26613-01
Commit: 8e71e96724

.NET Core SDKs installed:
2.2.100-preview1-009013 [C:\michelm\optimization\output\CLRx64WINmas\IBC\clix64\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.0-preview1-34355 [C:\michelm\optimization\output\CLRx64WINmas\IBC\clix64\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.0-preview1-34355 [C:\michelm\optimization\output\CLRx64WINmas\IBC\clix64\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.0-preview1-26609-02 [C:\michelm\optimization\output\CLRx64WINmas\IBC\clix64\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.0-preview1-26613-01 [C:\michelm\optimization\output\CLRx64WINmas\IBC\clix64\shared\Microsoft.NETCore.App]

[livarcocc]

So, running dotnet <path_to_your_application>.dll will not spawn multiple processes.

Since 2.1.300, we actually have other servers that are long running: we have vbcscompiler, which is the one you were referring to above. We have the razor compiler and msbuild node re-use server.

To prevent all of them from running, you can do the following:

Use -p:UseRazorBuildServer=false to disable the Razor (rzc) server.

Use -p:UseSharedCompilation=false to disable the Roslyn (vbcscompiler) server.

For MSBuild, pass /nodeReuse:false on the command line to disable node re-use.

You may get inner loop perf degradation for doing that. Another alternative is to run dotnet build-server shutdown after you are done developing.

[adiaaida]

@jorive

[jorive]

@livarcocc Is there an environment variable to pass this implicitly to the build tools in the lab?

[livarcocc]

The first of the values I shared above can be set and environment variables. For MSBuild node re-use, you can set MSBUILDDISABLENODEREUSE

[matkoch]

I think dotnet CLI should support something like Gradle with --no-daemon... Setting three environment variables is surely not over-complicated, but it's too excessive to express something so small and simple as _don't leave any processes behind_.

[matkoch]

The first of the values I shared above can be set and environment variables. For MSBuild node re-use, you can set MSBUILDDISABLENODEREUSE

What are the other environment variables a.k.a. where is this documented? What is the suggested approach to cover previous and current versions of dotnet CLI to not spawn other processes? (we are providing build infrastructure, so previous versions matter as well)

[livarcocc]

UseRazorBuildServer and UseSharedCompilation.

Not sure if there is a place where all of them are documented together.

cc @KathleenDollard for documentation.

[matkoch]

@livarcocc thanks, but this doesn't fully answer the question. Since which version are processes kept alive? Since when are the environment variables supported? And would you consider a more concise approach to say _don't leave anything behind_?

[livarcocc]

I believe for Roslyn, they enabled it in 2.1.200. For the others, it started in 2.1.300. The concise approach you suggest above, seems great.

@peterhuene @KathleenDollard how do you feel about something similar to a --no-daemonfor not spawning child processes?

Also, keep in mind that you can use dotnet build-server shutdown to turn off the server.

Another thing we have been looking at is a dotnet config command, that you could use to persist your settings, per repo, per user or per machine. Though that's still in its early stages of thought, not even code yet.

Does this help?

[matkoch]

@livarcocc now I'm fully satisfied 👍

I've read about the dotnet build-server shutdown, but it could potentially shutdown too much. For instance when testing a build locally while having an IDE running. Not sure though about all the implications you're having with the build server.

For me personally, something like --no-daemon would be the perfect fit. Configuration file is too much already :) Let's see what the others think, and I would create a new issue from that.

Thanks!

[peterhuene]

I think an option to disable the servers for restore/build/publish would be a good addition. I would probably name it something along the lines of --no-servers though.

[nitzel]

Are there any updates on this @peterhuene @livarcocc ?

[peterhuene]

Hi @nitzel. There's been no update as I don't think an issue to implement this was ever filed (as far as I'm aware).

@livarcocc what do you think about implementing this option for our MSBuild forwarding commands in 3.0?

[nitzel]

Thank you for looking into this. Currently we need to set -p:UseSharedCompilation=false and /m:1 for dotnet build to avoid processes hanging around after the compilation.
To stop the second process spawned by dotnet run .. we're using taskkill /f /T /pid <pid-of-dotnet-run> to take down both processes, but that seems sub optimal to me.

[livarcocc]

hey @peterhuene I think having a switch that would encompass all our long running servers makes sense. Feel free to file a new issue for that and link it here.

[peterhuene]

I've opened https://github.com/dotnet/cli/issues/11424 and set it to the 3.0 milestone.