NAnt czy MSBuild, który wybrać i kiedy?

Zdaję sobie sprawę, że istnieją inne pytania związane z NAnt i MSBuild na temat przepełnienia stosu, ale nie mogłem znaleźć bezpośredniego porównania między nimi, więc oto pytanie.

Kiedy należy wybrać NAnt zamiast MSBuild? Który jest lepszy do czego? Czy NAnt jest bardziej odpowiedni do projektów domowych / open source i MSBuild do projektów służbowych? Jakie jest doświadczenie z którymkolwiek z tych dwóch?

W tym tygodniu przeprowadziłem podobne dochodzenie. Oto, co udało mi się ustalić:

NIE:

• Wieloplatformowy (obsługuje Linux / Mono). Może to być przydatne na przykład do zainstalowania witryny sieci Web w wielu celach (to jest Linux Apache i Windows IIS).
• W 95% składnia podobna do Ant (łatwa do zdobycia dla obecnych użytkowników Ant lub twórców Javy)
• Integracja z NUnit do uruchamiania testów jednostkowych w ramach kompilacji oraz z NDoc do tworzenia dokumentacji produktu.

MSBuild:

• Wbudowany w .NET.
• Zintegrowany z Visual Studio
• Łatwe rozpoczęcie pracy z programem MSBuild w programie Visual Studio - to wszystko za kulisami. Jeśli chcesz wejść głębiej, możesz ręcznie edytować pliki.

Subiektywne różnice: (YMMV)

• Dokumentacja NAnt jest trochę prostsza. Na przykład odwołanie do zadania programu MSBuild zawiera listę „Zadanie CSC - opisuje zadanie CSC i jego parametry” (dzięki za „pomoc”?), A odniesienie do zadania NAnt „csc - kompiluje programy C #”. AKTUALIZACJA: Zauważyłem, że dokumentacja MSBuild została ulepszona i jest teraz znacznie lepsza (prawdopodobnie na równi z NAnt).
• Nie jest łatwo dowiedzieć się, jak edytować źródło skryptu kompilacji (plik *. * Proj) bezpośrednio z poziomu programu Visual Studio. Z NAnt mam po prostu Visual Studio traktuję skrypt .build jako plik XML.
• Najwyraźniej w programie Visual Studio projekty aplikacji sieci Web nie otrzymują domyślnie pliku *. * Proj, więc miałem duże trudności ze zrozumieniem, jak nawet uruchomić MSBuild w moim, aby utworzyć skrypt wdrożenia.
• NAnt nie jest wbudowany w Visual Studio i musi zostać dodany za pomocą dodatku lub jako „narzędzie zewnętrzne”. To trochę trudne do skonfigurowania.
• (Edytuj :) Jeden z moich współpracowników wspomniał o tym - jeśli chcesz skonfigurować maszynę do kompilacji przy użyciu CruiseControl do ciągłej integracji, CruiseControl ładnie integruje się z NAnt po wyjęciu z pudełka. AKTUALIZACJA: CruiseControl ma również zadanie MSBuild .
• Zobacz komentarze poniżej, aby uzyskać pełne i aktualne omówienie subiektywnych różnic.

Jedną z głównych zalet MSBuild (na platformach Windows) jest to, że jest częścią samego .NET. Oznacza to, że na każdym komputerze z systemem Windows zaktualizowanym za pomocą usługi Windows Update będzie dostępny program MSBuild. Dodaj do tego fakt, że kompilator C # jest również częścią samego .NET i masz platformę, która może budować projekty na czystych maszynach. Nie ma potrzeby instalowania behemota Visual Studio. Z drugiej strony NAnt musi być jawnie zainstalowany przed uruchomieniem kompilacji.

Dla przypomnienia, w przeszłości używałem NMake, Make, Ant, Rake, NAnt i MSBuild na nietrywialnych kompilacjach (w tej kolejności). Moim ulubionym jest MSBuild, bez dwóch zdań (i nie faworyzuję go, ponieważ „tego używa Visual Studio”). IMHO, jest to bardzo niedoceniane narzędzie do budowania.

Porównałbym NAnt i MSBuild do różnicy między programowaniem proceduralnym i funkcjonalnym. NAnt jest dość prosty i dostajesz to, co widzisz. Z drugiej strony MSBuild wymaga nieco więcej przemyśleń. Krzywa uczenia się jest bardziej stroma. Ale kiedy już to zrozumiesz, możesz z nim zrobić niesamowite rzeczy.

Dlatego polecałbym przyjrzeć się MSBuild, jeśli również skłaniasz się ku programowaniu w stylu funkcjonalnym lub logicznym - jeśli chcesz zainwestować trochę czasu i wysiłku, zanim zobaczysz namacalne rezultaty (oczywiście, jestem również głęboko przekonany, że inwestycja w końcu się opłaca, a ty może wydajniej robić potężniejsze rzeczy).

Osobiście używam obu - do tego samego projektu.

MSBuild świetnie radzi sobie z budowaniem rozwiązań i projektów Visual Studio - do tego jest przeznaczony.

Moim zdaniem NAnt łatwiej jest edytować ręcznie - szczególnie jeśli znasz już Anta. NAnt może bardzo łatwo wywołać MSBuild za pomocą NAntContrib. Tak więc ręcznie tworzę skrypt NAnt, aby wykonywać takie czynności, jak kopiowanie zbudowanych plików, czyszczenie itp. - i wywołuję MSBuild, aby wykonać rzeczywistą część „zamień mój kod źródłowy C # na zestawy”.

Jeśli potrzebujesz przykładu, spójrz na mój plik kompilacji buforów protokołów . (Nie twierdziłbym, że to wspaniały skrypt NAnt, ale spełnia swoje zadanie).

NAnt ma więcej funkcji po wyjęciu z pudełka, ale MSBuild ma znacznie lepszą strukturę podstawową (skały metadanych elementów), co znacznie ułatwia tworzenie skryptów MSBuild wielokrotnego użytku.

Zrozumienie programu MSBuild zajmuje trochę czasu, ale gdy już to zrobisz, jest to bardzo miłe.

Materiały do ​​nauki:

• Wewnątrz aparatu Microsoft Build Engine: korzystanie z programu MSBuild i Team Foundation Build
  autorstwa Sayeda Ibrahima Hashimi (styczeń, 2009)
• Wdrażanie aplikacji .NET: nauka MSBuild i ClickOnce przez: Sayed
  by Y. Hashimi (wrzesień 2008)

KISS = Użyj MSBuild.

Po co dodawać coś innego do mieszanki, skoro masz coś, co po wyjęciu z pudełka wykona rozsądną pracę? Kiedy pojawił się MSBuild, NAnt zmarł. I Mono będzie miało wdrożenie MSBuild, ( xbuild ).

DRY = Użyj MSBuild.

Zadaj sobie pytanie, czego oczekujesz od systemu kompilacji? Chcę systemu kompilacji, który jest również używany przez moje IDE, zamiast obsługiwać dwie różne konfiguracje.

Osobiście chciałbym usłyszeć prawdziwe argumenty za NAnt, ponieważ po prostu nie mogę wymyślić żadnego, który naprawdę wytrzymuje.

Zauważyłem, że kilka plakatów wspomniało o konieczności ręcznej edycji plików .csproj (lub .vbproj itp.).

MSBuild umożliwia dostosowywanie tych plików. * Proj za pomocą plików .user. Jeśli mam projekt o nazwie MyCreativelyNamedProject.csproj i chcę dostosować w nim zadania MSBuild, mogę utworzyć plik o nazwie MyCreativelyNamedProject.csproj.user i użyć CustomBeforeMicrosoftCommonTargets i CustomAfterMicrosoftCommonTargets, aby dostosować te pliki.

Ponadto zarówno NAnt, jak i MSBuild można dostosować do zawartości serca za pomocą niestandardowych zadań MSBuild i rozszerzeń NantContrib.

Tak więc używanie NAnt lub MSBuild naprawdę sprowadza się do znajomości:

• Jeśli znasz już Ant, użyj NAnt. Krzywa uczenia się będzie bardzo łatwa.
• Jeśli nie znasz żadnego narzędzia, program MSBuild jest już zintegrowany z programem Visual Studio i nie wymaga dodatkowych narzędzi.

Warto również dodać, że MSBuild ma prawie gwarancję działania ze wszystkimi nowymi wersjami .NET i Visual Studio, gdy tylko zostaną wydane, podczas gdy NAnt może mieć pewne opóźnienie.

Używam obu w tym, że moje skrypty NAnt wywołują MSBuild. Moim głównym powodem pozostania w NAnt jest izolacja . Pozwólcie mi wyjaśnić, dlaczego uważam, że jest to ważne:

1. Dodawanie zależności do projektu. Plik kompilacji NAnt jest obcy dla Visual Studio (w moim przypadku uważam to za profesjonalistę), więc Visual Studio nie próbuje nic z nim zrobić. Zadania programu MSBuild są osadzone, więc stanowią część rozwiązania i mogą odnosić się do innych zadań programu MSBuild. Otrzymałem kod źródłowy od kogoś innego tylko po to, aby dowiedzieć się, że nie mogę zbudować, ponieważ zadania społeczności MSBuild nie zostały zainstalowane. Szczególnie frustrujące jest to, że program Visual Studio po prostu nie mógł się skompilować i wyrzucił kilka błędów, które sprawiły, że traciłem czas na debugowanie. Dzieje się tak pomimo faktu, że żądana kompilacja mogłaby przebiegać dalej (na przykład jako kompilacja debugowania) bez niektórych dodatków zadania MSBuild. Krótko mówiąc: nie lubię dodawać zależności do mojego projektu, jeśli mogę tego uniknąć .

2. Nie ufam Visual Studio tak bardzo, jak mogę rzucić jego zespół programistów. Wynika to z wczesnych dni Visual Studio, kiedy to masakruje mój HTML. Na przykład nadal nie korzystam z projektanta (na konferencji ostatnio stwierdziłem, że koledzy zrobili to samo). Odkryłem, że Visual Studio może zepsuć zależności i numery wersji w pliku DLL (nie mogę tego powtórzyć, ale działo się to konsekwentnie w projekcie i spowodowało wiele żalu i straconego czasu). Skorzystałem z procedury kompilacji, która używa programu Visual Studio do kompilowania tylko w trybie debugowania. Do produkcji używam NAnt, aby kontrolować wszystko z zewnątrz . Visual Studio po prostu nie może już dłużej ingerować, jeśli kompiluję przy użyciu NAnt.

PS: Jestem programistą WWW i nie zajmuję się programowaniem w Windows Forms.

Chociaż nie jestem zaznajomiony z MsBuild, mam wrażenie, że niektóre kluczowe różnice po obu stronach można uzupełnić dodatkami:

• MsBuildTasks
• NantContrib

Niedawno musiałem zbudować projekt Silverlight w Nant. Odkryłem, że życie byłoby łatwiejsze, gdybym po prostu zrobił to z MsBuild - w końcu wywołałem zadanie MsBuild z poziomu skryptu Nant, więc przypuszczam, że mieszanie i dopasowywanie tych dwóch nie jest zbyt niezwykłe.

Poza tym przypuszczam, że będzie to kwestia osobistych preferencji - oczywiście możesz zarządzać niektórymi / większością funkcji MsBuild z poziomu Visual Studio, jeśli to lubisz. Nant wydaje się bardziej elastyczny i lepiej dostosowany, jeśli wolisz ręcznie pisać skrypty, a jeśli pochodzisz ze świata Java, prawdopodobnie będziesz z nim jak w domu.

Skończyło się na używaniu obu. Podczas przeprojektowywania naszego systemu kompilacji napotkałem trudny problem. Mianowicie, nie mogłem pozbyć się .vcproj (i rodziny), ponieważ wszyscy używaliśmy VS do aktualizacji plików projektu, ustawień i konfiguracji. Tak więc bez ogromnego procesu powielania i podatnego na błędy nie mogliśmy oprzeć naszego systemu kompilacji na nowym zestawie plików.

Z tego powodu zdecydowałem się zachować pliki „proj” VS i użyć MSBuild (są to pliki MSBuild, przynajmniej VS2005 i VS2008 używają plików projektu MSBuild). Do wszystkiego innego (konfiguracja niestandardowa, testy jednostkowe, pakowanie, przygotowanie dokumentacji ...) użyłem NAnt.

Do ciągłej integracji użyłem CruiseControl. Więc mieliśmy skrypty CC, które wyzwalały zadania NAnt, które do budowania wykorzystywały MSBuild.

Ostatnia uwaga: program MSBuild NIE obsługuje projektów instalacyjnych! Więc utkniesz z wywołaniem DevEnv.com lub bezpośrednim użyciem programu Visual Studio. Właśnie to zrobiłem, ale domyślnie wyłączyłem projekt instalacyjny ze wszystkich konfiguracji rozwiązań, ponieważ programiści normalnie nie musieliby ich tworzyć, a jeśli to zrobią, mogą ręcznie wybrać, aby je zbudować.

Niedawno przeszedłem z NAnt na MSBuild ze względu na jego zdolność do tworzenia rozwiązań VS. Nadal jednak czasami używam NAnt.

Możesz również chcieć sprawdzić zadania społeczności MSBuild, które są podobne do NAntContrib.

Dokumentacja i samouczki dostępne dla NAnt ułatwiają rozpoczęcie nauki skryptów budowania z NAnt. Kiedy już opanowałem NAnt i tworzyłem skrypty budujące, zacząłem tłumaczyć tę wiedzę na MSBuild (zrobiłem X w NAnt, jak zrobić X w MSBuild?). Dokumentacja Microsoftu zwykle zakłada dość wysoki poziom wiedzy, zanim stanie się użyteczna.

Przyczyną przełączania się z NAnt na MSBuild jest to, że program MSBuild jest bardziej aktualny. Niestety, ostatnie wydanie NAnt miało miejsce 8 grudnia 2007, podczas gdy MSBuild 4.0 (.NET 4.0) nie jest daleko. Wygląda na to, że projekt NAnt umarł.

Jeśli znajdziesz dobrą dokumentację dla kogoś, kto dopiero zaczyna uczyć się tworzenia skryptów kompilacji przy użyciu programu MSBuild, pomiń NAnt i przejdź bezpośrednio do programu MSBuild. Jeśli NAnt kiedykolwiek wyjdzie z nowym wydaniem, to rozważę pozostanie przy NAnt, ale teraz pozostają w tyle.

Używamy obu. NAnt jest odpowiedzialny za wszystkie czynności związane ze skryptami, takie jak kopiowanie, wdrażanie w IIS , tworzenie pakietów, a MSBuild jest odpowiedzialny za budowanie rozwiązania. Dzięki temu możemy uniknąć problemów z nieobsługiwanym .NET 4.0 przez nową wersję NAnt.

NAnt jest również bardziej skalowalny. Jeśli chcemy przenieść skrypty wdrożeniowe na serwery produkcyjne, to tylko kopiujemy plik build i instalujemy odpowiednią wersję .NET - brak problemów Visual Studio z plikami csproj :)

YDeliver by Manoj to framework do budowania zbudowany na bazie PSake. Posiada bogaty zestaw funkcji bibliotecznych, możliwość definiowania przepływów pracy i wykorzystaliśmy go do dostarczenia ponad sześciu projektów przedsiębiorstwa do produkcji.

Używaj go w połączeniu z TeamCity , CruiseControl lub czymkolwiek, co może obsługiwać PowerShell .

Używamy FlubuCore. Jest to biblioteka C # typu open source do tworzenia projektów i wykonywania skryptów wdrożeniowych przy użyciu kodu C #.

Prosty przykład użycia flubu:

protected override void ConfigureTargets(ITaskContext session)
{           

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");
}

Więcej informacji o flubu i o tym, jak zacząć, można znaleźć tutaj: choice-for-build-tool-msbuild-nant-or-something-else