Dlaczego powinienem używać MSBuild zamiast plików Visual Studio Solution?

Używamy TeamCity do ciągłej integracji, a my budujemy nasze wydania za pomocą pliku rozwiązania (.sln). W przeszłości korzystałem z Makefiles dla różnych systemów, ale nigdy nie budowałem msbuilda (co słyszałem, to trochę jak Makefiles + mashup XML). Widziałem wiele postów na temat używania msbuild bezpośrednio zamiast plików rozwiązania, ale nie widzę bardzo jasnej odpowiedzi na pytanie, dlaczego to zrobić.

Dlaczego więc mielibyśmy zawracać sobie głowę migracją z plików rozwiązania do „makefile” MSBuild? Mamy kilka wydań, które różnią się #define (featurized builds), ale w większości wszystko działa.

Bardziej niepokojące jest to, że teraz musielibyśmy utrzymywać dwa systemy podczas dodawania projektów / kodu źródłowego.

AKTUALIZACJA:

Czy ludzie mogą rzucić światło na cykl życia i wzajemne oddziaływanie trzech następujących elementów?

1. Plik .sln programu Visual Studio
2. Wiele plików .csproj na poziomie projektu (rozumiem skrypty msbuild „sub”)
3. Niestandardowy skrypt msbuild

Czy można bezpiecznie powiedzieć, że .sln i .csproj są konsumowane / obsługiwane jak zwykle z poziomu graficznego interfejsu GUI programu Visual Studio IDE, podczas gdy niestandardowy skrypt msbuild jest pisany ręcznie i zwykle zużywa już istniejącą indywidualną wersję .csproj „w stanie, w jakim jest”? To jeden ze sposobów, w jaki widzę zmniejszenie nakładania się / duplikatów w konserwacji ...

Byłbym wdzięczny za trochę światła z doświadczeń operacyjnych innych ludzi

Po pierwsze, plik rozwiązania niemal w magiczny sposób staje się plikiem MSBuild, gdy MSBuild go wykonuje - co dzieje się, gdy budujesz rozwiązanie w Visual Studio. Ponadto wszystkie pliki projektu to tylko pliki msbuild zarządzane przez Visual Studio. W rzeczywistości pliki projektu obsługują większość naprawdę brudnej pracy tutaj, bez względu na to, czy budujesz z rozwiązań, czy z niestandardowego skryptu msbuild.

Korzystamy również z TeamCity do tworzenia i publikowania aplikacji i zwykle kończą się niestandardowymi skryptami msbuild dla większości projektów. Rola, jaką odgrywają te skrypty - co nie jest tak naprawdę łatwe w przypadku pliku rozwiązania - polega na pakowaniu projektu do wdrożenia lub dystrybucji. Zazwyczaj te skrypty obsługują niektóre bardziej operacyjne aspekty rzeczy - na przykład budowanie projektu internetowego do określonego folderu lub kopiowanie w uruchomionych konfiguracjach, w przeciwieństwie do konfiguracji programistycznych. Ciężkie podnoszenie zwykle wykonuje się w samych plikach projektu - skrypt kompilacji tylko je odwołuje, nie próbujemy odtworzyć tego koła. Ogólnie działa świetnie i nie jest tak naprawdę zduplikowanym kodem.

Plik makefile dla msbuild to plik .sln (lub plik vcproj).

Typowy wiersz polecenia msbuild mógłby wyglądać następująco:

msbuild /p:Configuration=Release BigProject.sln

Celem użycia msbuild jest umożliwienie skryptowania i automatyzacji procesu kompilacji. Bez względu na to, czy zdawałeś sobie z tego sprawę, TeamCity od zawsze używa msbuild.

Pozwól mi zaoferować swoje zdanie na temat tego pytania.

Chociaż z pewnością możesz po prostu użyć pliku .SLN jako „procesu kompilacji”, sam plik tak naprawdę nie stanowi procesu kompilacji. Plik Solution jest tak naprawdę tylko częścią Visual Studio i służy do programowania. Ale Visual Studio to tylko część procesu kompilacji i wydania. Nie możesz polegać na rozwiązaniach do zarządzania kompilacją, a rozwiązania z pewnością nie oferują skalowalnej sytuacji kompilacji.

Głównym celem ustanowienia procesu kompilacji jest tworzenie niezawodnych kompilacji. Innymi słowy, proces kompilacji jest tak niezawodny, że bez względu na konfigurację kompilacji otrzymasz przewidywalne wyniki kompilacji. Za każdym razem, każda maszyna. Wynikiem przewidywalnej i niezawodnej kompilacji jest to, że proces testowania, wdrażania i wydawania może być wysoce zautomatyzowany, co dodatkowo zmniejsza ryzyko błędu ludzkiego.

Ustanowienie procesu kompilacji wymaga inwestycji, ale w niektórych przypadkach inwestycja jest wymagana. Oto kilka czynników, które sprzyjają procesowi msbuild:

• Twój produkt ma wiele zespołów (międzyfunkcyjnych lub innych), które pracują w tym samym projekcie zespołowym
• Twoja organizacja ma tylko jeden projekt zespołowy (powinno tak być w przypadku 99% tradycyjnych sklepów, nawet tych z ponad 200 programistami)
• Masz ponad 20 projektów, które należy zbudować, z których niektóre zależą od innych i są prowadzone przez różne zespoły
• Twój produkt zawiera wiele technologii .NET (C #, C ++, VB, F #, ASP.NET itp.), A nawet technologie inne niż .NET (Grunt, węzeł, npm, Java itp.)
• Twój produkt jest zależny od wagi ciężkiej lub jest zbudowany na platformie wagi ciężkiej. SharePoint, jako przykład

Pozwól, że podam przykład rozwinięcia mojej ostatniej kwestii. Moja obecna firma zajmuje się programowaniem SharePoint. Programowanie SharePoint co najmniej wymaga zainstalowania programu SharePoint Foundation, aby wykonywać kompilacje w projektach SharePoint. Mówiąc o lekkim serwerze kompilacji, całkowicie niepraktyczne jest wymaganie, aby serwer kompilacji miał zainstalowany program SharePoint. SharePoint jest nie tylko bestią o wysokich wymaganiach, ale miałby poważny wpływ na wydajność kompilacji - a kompilacje powinny być tak szybkie i uproszczone, jak to możliwe. Wykorzystanie MSBuild pozwala mi wyeliminować ten wymóg instalacji na serwerze kompilacji. W rzeczywistości nasz serwer kompilacji nie ma innych wymagań instalacyjnych niż platforma .NET (wymagana przez MSBuild) i Węzeł.

Jako odniesienie polecam sprawdzenie tej książki Sayeda Ibrahima Hashimi: http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie=UTF8&qid=1412014650&sr= 8-1-fkmr0 i słowa kluczowe = msbuild + niezawodny + build

To jest pytanie, które zadałem sobie kilka miesięcy temu! Wszystko ładnie skonfigurowaliśmy:

• Plik rozwiązania ładnie w katalogu głównym repozytoriów
• Twórz kroki skonfigurowane w Teamcity, np
  • Przywróć pakiety NuGet
  • Zbuduj rozwiązanie
  • Przeprowadź testy jednostkowe
  • Skonfiguruj środowisko testowe integracji
  • Przeprowadź testy integracyjne
  • Zniszcz środowisko testowe integracji
  • Utwórz pakiet wdrażania
  • Zbuduj skrypt migracji

A potem, jeśli chodzi o odtwarzalność, stało się jasne, że wynik ten był niski. Kiedy pozwalasz TeamCity na tworzenie skryptu kompilacji, trudno jest reprodukować podobne wyniki na swoim komputerze.

Gdy masz skrypt kompilacji, skrypt kompilacji wie wszystko, co należy zrobić, i ma wszystkie zmienne na swoim miejscu. Gdy używasz serwera CI jako skryptu kompilacji i zdarzają się pewne problemy, takie jak niepowodzenie złożonego testu lub konieczność ręcznego zbudowania pakietu wdrażania (jak w moim przykładzie), musisz złożyć wszystkie etapy kompilacji ręcznie.

Tak więc, w zwarcia , dlaczego (MS) skrypt budować? Ponieważ będziesz mieć więcej wymagań, jeśli chodzi o twoją kompilację. Prawdopodobnie chcesz przeprowadzić testy i wygenerować z nich artefakty. Prawdopodobnie chcesz wykonywać wdrożenia. A gdy wszystko, co chcesz, musi być uruchomione, bez względu na to, czy znajduje się na serwerze kompilacji, czy na komputerze, nie może skończyć się nigdzie indziej niż w skrypcie kompilacji.