Używanie współdzielonej kompilacji z Roslyn w samodzielnym środowisku kompilacji?

Question

Niedawno uaktualniliśmy nasz system kompilacji od VS 2013 do 2015 Update 2, a nasze czasy budowy znacznie wzrosły. Nasze środowisko kompilacji jest samoistne, więc uruchamiamy MSBuild z pakietu (używając devpath), a nie z zainstalowanej lokalizacji. Patrząc na logi, wydaje się, że wzrost czasu kompilacji prawie w całości dotyczy zadania kompilacji csc. Zainstalowanie MSBuild na maszynie nie ma żadnego wpływu, chociaż jeśli uruchamiamy z zainstalowanej lokalizacji, a nie z naszej niezależnej lokalizacji, czasy kompilacji są podobne do tego, co widzimy w 2013 roku. Podczas uruchamiania z zainstalowanej lokalizacji widzimy, że współdzielona kompilacja jest realizowana. używany z wiadomości "Używanie kompilacji współdzielonej z kompilatorem z katalogu: C: \ Program Files (x86) \ MSBuild \ 14.0 \ bin". W tej chwili jesteśmy pod wrażeniem, że włączenie wspólnej kompilacji pomoże nam w naszych czasach kompilacji, ale nie byliśmy w stanie sprawić, by działała ona z naszego niezależnego środowiska. Ustawienie "UseSharedCompilation" na true nie ma wpływu i nie spowoduje wyświetlenia powyższego komunikatu podczas kompilacji.

Czy istnieje sposób na włączenie kompilacji współdzielonej z Roslyn podczas uruchamiania MSBuild ze ścieżki innej niż lokalizacja zainstalowana?

Answer 1

Czy próbowałeś całkowicie przesłonić zadanie "Csc"? Oceniłem przykładowy projekt CSharp z wiersza poleceń za pomocą przełącznika preproces (tj. "/pp:out.txt"), otworzyłem "out.txt" i odkryłem, że jedyne odniesienia do "UseSharedCompilation" mają jeden kształt lub inny związany z zadaniem kompilacji Csc.

Uderzenie w ciemne wyszukiwanie wszystkich plików tekstowych na GitHub.com ujawniło E! prawdziwa hollywoodzka opowieść o UseSharedCompilation. Poniżej zamieszczona jest z „Microsoft.Net.Compilers” Pakiet Nuget:

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

Zatem zgodnie z powyższym Xml komentarz, trzeba będzie zatrudnić jakąś MSBuild sztuczek, aby zrealizować swoje samodzielne gromadzenie środowiska z " UseSharedCompilation ". Pełen tekst powyższego fragmentu znajduje się pod adresem https://raw.githubusercontent.com/dotnet/roslyn/c5b249b16f7d67ee1645a1b75fa3de6f16314672/build/NuGetAdditionalFiles/Microsoft.Net.Compilers.props.

Answer 2

Okazuje się, że wspólna kompilacja nie była naszym problemem. Ostatecznie musieliśmy uruchomić ngen.exe na csc.exe i większość dll zależy od tego. To wstępnie je kompiluje, więc kompilacja JIT nie zdarza się dla każdego połączenia exe. Visual Studio robi to podczas instalacji, ale jeśli umieścisz je w innym katalogu, musisz zrobić to ponownie, ponieważ wyszukuje je według lokalizacji. Właśnie dodaliśmy krok, gdy otworzyliśmy okno rejestracji, aby uruchomić ngen na potrzebnych plikach, ponieważ jest to dość szybkie. Bez niego csc.exe zajmowało około 10 sekund dla każdego połączenia.