Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using Shared Compilation with Roslyn in a self contained build environment?

Tags:

roslyn

We have recently upgraded our build system from VS 2013 to 2015 Update 2 and our build times have increased dramatically. Our build environment is self-contained, so we run MSBuild from a package (using devpath) rather than from an installed location. Looking at the logs it appears that the increase in build time is almost all in the csc build task. Installing MSBuild on the machine has no impact, although if we run from the installed location rather than our self-contained location the build times are similar to what we see with 2013. When running from an installed location we can see that shared compliation is being used from the message "Using shared compilation with compiler from directory: C:\Program Files (x86)\MSBuild\14.0\bin". At the moment we are under the impression that enabling shared compilation will help with our build times, but we haven't been able to get it working from our self-contained environment. Setting "UseSharedCompilation" to true has no impact and doesn't result in the message above during the build.

Is there a way to enable shared compilation with Roslyn when running MSBuild from a path other than the installed location?

like image 580
Jperrigo Avatar asked Sep 12 '16 20:09

Jperrigo


Video Answer


2 Answers

Have you tried overriding the "Csc" task altogether? I evaluated a sample CSharp project from the command-line using the preprocess (i.e., "/pp:out.txt") switch, opened up "out.txt", and found that the only references to "UseSharedCompilation" are in one shape or another related to the Csc build task.

A stab in the dark search of all text files on GitHub.com revealed the E! true Hollywood story of UseSharedCompilation. The following is from the NuGet Package 'Microsoft.Net.Compilers':

  <!-- The UsingTask, UseSharedCompilation, and ToolPath/Exe variables all interact to 
   choose which compiler path to use and whether or not to use the compiler server.
   If UsingTask and UseSharedCompilation are set then the compiler server next to the
   task will be used (i.e., the one in this package).
   If UseSharedCompilation is false or ToolPath/Exe are set the compiler server will
   not be used and the compiler exe at the ToolPath, if set, will be executed, otherwise
   the executable in the MSBuild install path will be executed. -->

So, according to the above Xml Comment, you will have to employ some MSBuild trickery to realize your self-contained build environment with the "UseSharedCompilation". For the full text of the above snippet, see https://raw.githubusercontent.com/dotnet/roslyn/c5b249b16f7d67ee1645a1b75fa3de6f16314672/build/NuGetAdditionalFiles/Microsoft.Net.Compilers.props.

like image 191
Brad R. Marshall Avatar answered Sep 19 '22 09:09

Brad R. Marshall


It turns out that shared compilation wasn't our issue. Ultimately we needed to run ngen.exe on csc.exe and most of the dll's it depends on. This pre-compiles them so the JIT compilation doesn't happen for every single call of the exe. Visual Studio does this when you install, but if you put them in another directory you have to do it again, as it looks them up by location. We just added a step when we opened the enlistment window to run ngen on the necessary files, as it is pretty quick. Without it csc.exe was taking around 10 seconds for every single call.

like image 40
Jperrigo Avatar answered Sep 17 '22 09:09

Jperrigo