Sdk: Friendly way to shutdown VBCSCompiler and msbuild nodes

[nguerrera]

There are scenarios where it's important to shutdown the compiler and msbuild processes that can be reused to speed up subsequent builds. (Note these processes don't exist on Core yet, but are coming very soon).

We typically recommend shutting down these proceeses before and after CI.

VBCSCompiler supports a ~stop~ -shutdown argument, but the path to VBCSCompiler.dll within the CLI should remain an implementation detail. I don't know what the equivalent would be for msbuild.

Perhaps we should have a single verb, like dotnet stop-build-servers (actual name TBD), that shuts down all of these.

cc @jaredpar @AndyGerlicher @khyperia @livarcocc

[khyperia]

VBCSCompiler supports a stop argument

Nitpick: it's actually called -shutdown https://github.com/dotnet/roslyn/blob/614299ff83da9959fa07131c6d0ffbc58873b6ae/src/Compilers/Server/ServerShared/BuildServerController.cs#L150

[nguerrera]

@khyperia Thanks, not sure where I got stop from. I corrected the description.

[jaredpar]

That's my fault. I've been calling it stop in emails for some unexplainable reason 😦

[livarcocc]

@KathleenDollard I think there is still value is putting this command in the SDK, specially for CI servers and now that we will have two "persistent" services running as part of the SDK.

We just need a little bit of design to figure out what this command looks like.

[dasMulli]

actually.. what happens if you work on different projects simultaneously with different SDK versions (global.json)? do they connect to the same process or do they select compatible processes?

[livarcocc]

good question for @jaredpar and @AndyGerlicher

[dasMulli]

same goes for different msbuild versions.. cc @rainersigwald

[jaredpar]

actually.. what happens if you work on different projects simultaneously with different SDK versions (global.json)?

There is going to be one copy of the server for every Microsoft.Build.Tasks.CodeAnalysis.dll. If the different SDK cause different Microsoft.Build.Tasks.CodeAnalysis.dll to be used in the build process then there will be different VBCSCompiler servers spun up.

[rainersigwald]

MSBuild negotiates compatibility immediately after connecting to pipes and will disconnect if we don't see the expected handshake value, which is primarily based on version and includes some other things. The hash computation is spread into several places but is normally in CommunicationUtilities.

For actually shutting down MSBuild, we have an API for that: BuildManager.ShutdownAllNodes() (though we need to test it on Core).

[nguerrera]

This should be high priority. I've already gotten tripped up locally in 2.1.100 and lazily resorted to killing all dotnet.exe processes, which is not at all a safe thing to do in automation. We may even want to service 2.1.1xx with this. It's unfortunate that we shipped with vbcscompiler and not this already.

I'm going to upgrade my dotnet stop-build-servers to an official proposal. I think it's really just a matter of picking the command name. I'm open to any name here, but let's not delay too much more.

[KathleenDollard]

I agree we should do this.

I suggest a form (with the current pattern) that is something like

dotnet shutdown build-server

Is there anything else you can think of that would ever need to be stopped or shutdown. That can help us decide between those two verbs. I would like this to be very explicit, thus suggest build-server

@nguerrera in your initial post you used plural on servers. But this will just shut down the ones associated with the current process/just one if there are multiple spun up? Or will this kill all the build servers and compliers that can be found.

Is there any need for greater granularity?

[nguerrera]

It should kill only those with matching version to sdk being used. Plural was because there are 2 now: msbuild & vbcscompiler. It is not hard to imagine more: maybe f# will add one, we've talked about a sort of command line project system as a server before, etc.

I don't know if we need more granularity. Common use case is "stop everything that may still be running in order to speed up future builds". I can't think of case where I want to shutdown msbuild but not vbcscompiler or vice versa. It might make sense to at least reserve command real estate for that, though. Maybe something like this:

dotnet shutdown all
dotnet shutdown vbcscompiler
dotnet shutdown msbuild

[KathleenDollard]

I don't like not having the word "build" in what we are shutting down.

What if we want to shutdown watch? I can dream of other background processes. And if I saw all I'd worry about other SDK versions

Since you think it will almost always shutdown all the build processes, maybe this:

dotnet shutdown build
dotnet shutdown build vbcs-compiler
dotnet shutdown build msbulid
dotnet shutdown build --all-sdk-versions

with shutdown document as being for background processes/servers

Does that make sense?

[nguerrera]

Works for me. --all-sdk-versions is problematic to implement so I'd leave it out from the first turn of the crank. Also, I'm not sure we really need the separate options for vbcscompiler and msbuild so I'd leave them out at first too.

Basically, start with just dotnet shutdown build with confidence that we have real estate to evolve. Sound good?

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Kathleen Dollard [e-mail]
Sent: Sunday, March 11, 2018 9:55:43 AM
To: dotnet/cli
Cc: Nick Guerrera; Mention
Subject: Re: [dotnet/cli] Friendly way to shutdown VBCSCompiler and msbuild nodes (#8185)

I don't like not having the word "build" in what we are shutting down.

What if we want to shutdown watch? I can dream of other background processes. And if I saw all I'd worry about other SDK versions

Since you think it will almost always shutdown all the build processes, maybe this:

dotnet shutdown build
dotnet shutdown build vbcs-compiler
dotnet shutdown build msbulid
dotnet shutdown build --all-sdk-versions

with shutdown document as being for background processes/servers

Does that make sense?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcli%2Fissues%2F8185%23issuecomment-372130347&data=04%7C01%7CNick.Guerrera%40microsoft.com%7C027570f740b34db3be0708d58770ee24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563841465647041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=Ocjto9cshX4gjmwTkhisNyW%2BYh1IV3IzLGo7ZR4lOXg%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAEmzgBFn2N6md4k54-gTCjEIiXS-Fjdks5tdVcPgaJpZM4Q6H8g&data=04%7C01%7CNick.Guerrera%40microsoft.com%7C027570f740b34db3be0708d58770ee24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563841465647041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=eKLiucWvsu7BVTkhevXdN1gzKI6louL8fPuWdH%2BT2gI%3D&reserved=0.

[KathleenDollard]

Agree. Since we have options for the future, let's just do what we need.

[jaredpar]

Nit: should be vbcscompiler not vbcs-compiler. I don't know why we originally gave it that name but it is what it is at this point.

[dasMulli]

Is the plan for 2.1 still to create a "warm" razor compilation host similar to vbcs / msbuild nodes? (if I remember that correctly)
If so, it should also be respected for this command.

[livarcocc]

@rynowak to speak about the razor compilation server. I imagine we would want to include it here as well.

[rynowak]

Yes, we've already done this for Razor in 2.1. Agree that this needs to be part of a 'shutdown' as well.

What's the contract we need to implement to support this? MSBuild target?

[peterhuene]

Given that we're generally moving to a <resource-noun> <action-verb> model for the CLI UX, I propose:

dotnet server shutdown, which, by default, shuts down all "servers" dotnet knows about.

There would then be options such as --msbuild, --vbcscompiler, --razor that can be combined to shutdown only a subset of known servers. I'm open to other syntax to specify the subset (subcommands, perhaps?)

I'm not married to the noun of "server" ("daemon" might be a little too UNIX-y), so I'm open to suggestions here too. I'd prefer not to have a noun per type of server (i.e. msbuild-server shutdown, vbcscompiler shutdown, razor shutdown, etc.), but I can be persuaded.

@rynowak with respect to Razor, how do you shutdown the server currently? In order of preference for the CLI to shutdown your server: an API to shutdown the server, an external command to shutdown the server, and finally an MSBuild target to shutdown the server.

[rynowak]

We have a CLI tool (you can get the path to it from MSBuild) and we could easily add an MSBuild Task/Target that serves as a wrapper.

For an API, could you provide a little more detail? What form would that take and how would we ship it?

[peterhuene]

@rynowak something we could reference and invoke that takes care of whatever IPC is needed to shut the server process down. For example, Rainer linked to a method that can be called in the Microsoft.Build package (a netstandard lib), which is referenced from dotnet; presumably this will enable us to shutdown the msbuild server without having to invoke an msbuild target to do so.

Regarding your tool, is it already shipping as part of the SDK? If not, what's the delivery vehicle currently?

[rynowak]

The tool itself is shipped in a package/shared framework. Razor is kinda hybrid compiler/runtime and we expect the versions to match on the tool/server and the runtime libraries.

For that reason there isn't a great dependency for the CLI to take to shutdown Razor.

MSBuild sounds like something we can do unless you have more ideas I'm not considering 😕

[peterhuene]

The command will be implemented with a broken MSBuild and Razor shutdown.

Blocked on Microsoft/MSBuild#3151 for MSBuild shutdown to work.

Blocked on aspnet/Razor#2230 for Razor shutdown to work.

[peterhuene]

After some internal discussion, we feel that the top-level command should be buildserver so that it doesn't confuse users with other types of servers or with dotnet-serve.

Examples:

# Shutdown all build servers
$ dotnet buildserver shutdown

# Shutdown a specific build server
$ dotnet buildserver shutdown --razor

# Shutdown a subset of servers
$ dotnet buildserver shutdown --razor --msbuild

[peterhuene]

This has been fixed with dotnet/cli#8950.

[nguerrera]

@peterhuene Is there an issue tracking the follow-up post preview2 to this?

[peterhuene]

I've opened https://github.com/dotnet/cli/issues/8968.