Turn on UseSharedCompilation by default in the Microsoft.NET*.Compilers packages

[vsfeedback]

We have a largish solution - 180+ projects, 300k lines.

Due to issues with our TFS build server (still using TFS 2013) we have referenced the .NET Compiler package in all C# projects (currently V2.8.2).

On a new desktop machine (Intel 8700K) the solution initially took 2 min 30 secs to rebuild all.

Then something changed - I have been unable to discover what, or replicate this on other machines but the build started to take 1 minute. I thought it may be due to ngen'ing csc.exe in the compiler tools folder but this doesn't help on other machines.

After removing the .NET compiler package from all projects the build now takes 30 seconds.
I've replicated this on an older machine (Intel 2700K), where the build changed from 5+ minutes to 57 seconds.

1. why is the compiler package so much (5x) slower than the same thing built into VS?

2. is there currently any way through configuration or msbuild step to only run the .NET compiler package on the build server?
   V2 of Microsoft.CodeDom.Providers.DotNetCompilerPlatform has configuration to specify which compiler to use. Can we have the same thin for the Microsof.NET.Compilers package?

3. Any ideas how/why I'm getting a faster build time while still referencing the package (e.g the 1 minute time)?

4. Should I post these question on the Roslyn forums?

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/273289/nuget-package-netcompilers-5x-slower-than-built-in.html
VSTS ticketId: 633452
These are the original issue comments:
(no comments)
These are the original issue solutions:

Lee, Philip solved on 6/16/2018, 04:30 PM (2 days ago), 0 votes:

A solution for me, and answer to point 2), is to set the environment variable 'UseSharedCompilation' to 'true' on my dev machine. This means the VS compiler is used for building locally, but I can still use the Nuget package on the build server.

5x difference in speed is surprising.

Andy Gocke [MSFT] on 6/18/2018, 10:16 PM (35 sec ago):

Sorry you ran into this -- I can see why this would be surprising. Note that UseSharedCompilation is affecting the NuGet package here, so what's actually happening is you're using the package, but with the performance improvement from the compiler server.

We've historically resisted turning this on by default exactly because of the ASP.NET package you referenced. By using the compiler server, the bin/ directory will be locked, since the ASP.NET process will launch the compiler server. Now that ASP.NET has more fine-grained control over the compiler usage, I'll transfer this bug over to Github to track us enabling UseSharedCompilation by default in our packages.

[PhilPJL]

Note that turning on 'UseSharedCompilation' then shows up errors in Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props in any web apps. See aspnet/RoslynCodeDomProvider#52

[PhilPJL]

@agocke I'm not sure turning that environment variable on by default would be desirable. Wouldn't that defeat the point of having referenced the package? I know that's what I'm doing but I'm explicitly doing that now that I know about it.

[agocke]

@PhilPJL UseSharedCompilation is just a mode on the compiler. When you turn it on it doesn't change what version of the compiler you use, it just turns on the "server" mode that speeds up compilations. I'm presuming you reference the package to override the version of the compiler used to compile your code -- that shouldn't change, the same compiler version should be used with UseSharedCompilation. The only downside is that the server lives past a single compilation to share information, so it can lock the directory it lives in from being deleted.

There should be no other different behavior with UseSharedCompilation, so if there are any new errors produced that sounds like some bugs that we need to fix.

[agocke]

cc @jaredpar

[PhilPJL]

@agocke
We're using .NET compilers in a 'not supported' mode (#19128) because I removed the condition preventing their use on < MSBuild 15. That's so I can use them on our TFS 2015 build agent.
Setting UseSharedCompilation works fine locally but fails on the build agent.
So in this case defaulting to UseSharedCompilation would be an issue if we're not able to turn it off.

[agocke]

@PhilPJL We always allow customization of UseSharedCompilation, so if you set it to false that should be respected.