Friendly way to shutdown VBCSCompiler and msbuild nodes

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

[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).

[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.