2015-03-04 13 views
9

Mam rozwiązanie z 50 projektami, a każdy projekt ma minimum 100 plików (co moim zdaniem jest istotne).Duże opóźnienie, zanim Visual Studio zacznie budować

Problem polega na tym, że podczas budowania rozwiązania lub pojedynczego projektu występuje opóźnienie od 5 do 10 sekund przed zapisaniem okna "Kompilacja produkcji". Ustawienie "Szczegółowości produkcji" na "Diagnostyczne" nie daje żadnego wskazania, jaka jest przyczyna opóźnienia. Opóźnienie występuje nawet wtedy, gdy żadne pliki nie zostały zmienione (wcześniej zbudowane).

=== Build: 0 succeeded, 0 failed, 10 up-to-date, 0 skipped ========== 

Kiedy występują zmiany w wyjściowej Build mówi kompilacja trwało około 2 sekundy, aby zakończyć, jednak end end-to-trwa w przybliżeniu od 7 do 12 sekund.

wyjście Budowa:

1>(omitted) 
1>Time Elapsed 00:00:01.99 
========== Build: 1 succeeded, 0 failed, 9 up-to-date, 0 skipped ========== 

MSBuild:

Build succeeded. 
    0 Warning(s) 
    0 Error(s) 

Time Elapsed 00:00:02.17 

C:\Projects\SharedKernel.Tests> 

Running MSBuild za pośrednictwem wiersza poleceń nie ma takiego opóźnienia, że ​​2.17 sekundy to czas, po naciśnięciu na klawiaturze do zakończenia.

Z tego co wiem, same zadania msbuild są wykonywane szybko w Visual Studio, ale wygląda na to, że Visual Studio robi coś za kulisami przed uruchomieniem zadań msbuild, które powoduje to opóźnienie.

Kiedy sprawdzać Visual Studio (devenv.exe) chociaż Process Monitor zauważam połączeń do CreateFile, QueryDirectory i CloseFile dla każdego pliku i folderu w projekcie i zależnościach projektu. Wydaje się, że koreluje to z opóźnieniem, gdy patrzysz na oś czasu.

Jak zmniejszyć opóźnienie od momentu rozpoczęcia kompilowania procesu budowania z programu Visual Studio (prawy przycisk myszy na projekcie> kompilacja), do momentu, w którym rzeczywiście wystąpi kompilacja?

Spojrzałem na następujących odpowiedzi dla rozdzielczości, jednak albo nie zmniejszyć opóźnienie lub po prostu nie są stosowane:

+0

Kiedy "budujesz" rozwiązanie zgodnie z "Odbudowującym" rozwiązaniem, odbudowuje tylko pliki (.exes i takie), które się zmieniły, a więc jeśli dokonasz niewielkiej zmiany, to zajmie to znacznie więcej czasu, aby sprawdzić wszystkie pliki w twoim rozwiązaniu, szukając zmian, niż te małe zmiany (rzeczywisty budynek). Może to być niewielkie opóźnienie, którego doświadczasz. – CalebB

+0

Mam znaczne opóźnienie podczas wykonywania "Kompilacji", nawet jeśli żadne pliki się nie zmieniły. Opóźnienie jest dłuższe podczas wykonywania "Kompilacji" w "Rozwiązaniu". Mój szczególny przykład to "Kompilacja" na pojedynczym teście jednostkowym "Projekt". – Matthew

+0

Nawet jeśli nic się nie zmieniło, nadal będzie sprawdzać rozwiązanie lub projekt pod kątem zmian. – CalebB

Odpowiedz

0

myślę Twój problem to "Mam rozwiązanie z 50 projektami". Z mojego doświadczenia wynika, że ​​nie powinno się go używać do programowania. To powinno być używane tylko dla serwera kompilacji. To, co mógłbym zrobić, to zrobić kilka plików rozwiązania. Jeden duży ze wszystkimi projektami dla serwera kompilacji i kilkoma z kilkoma projektami do rozwoju. Opakowanie tych kilku rozwiązań powinno kierować się tym, co często się razem zmienia. Jeśli odpowiedź brzmi "wszystko", kwestionowałbym strukturę projektu.

Ponieważ tak naprawdę nie odpowiadam na pytanie, co dokładnie robi się w porównaniu z msbuild, normalnie piszę to jako komentarz. Ale moja reputacja w tej chwili nie wystarcza (pracując nad tym), ale ponieważ nikt inny tego nie zalecił, myślałem, że byłoby to warte odpowiedzi. A może to zbyt oczywiste, że nikt tego nie wskazał? Więc proszę, wybacz mi.