Я знаю, що є інші питання, пов'язані з NAnt та MSBuild щодо Stacka Overflow, але я не зміг знайти прямого порівняння між цими двома, тому ось питання.
Коли слід вибрати NAnt над MSBuild? Який краще для чого? Чи більше NAnt підходить для домашніх / відкритих проектів та MSBuild для робочих проектів? Який досвід роботи з будь-яким із цих двох?
Відповіді:
Я провів подібне розслідування цього тижня. Ось що я зміг визначити:
NAnt:
MSBuild:
Суб'єктивні відмінності: (YMMV)
Одне з головних розіграшів MSBuild для мене (на платформах Windows) - це те, що він є частиною самого .NET. Це означає, що будь-яка машина Windows, яка оновлюється оновленням Windows, матиме MSBuild. Додайте до цього той факт, що компілятор C # також є частиною самого .NET і у вас є платформа, яка може будувати проекти на чистих машинах. Не потрібно встановлювати бегемот Visual Studio. NAnt, з іншого боку, повинен бути явно встановлений до того, як може бути запущена збірка.
Тільки для запису я раніше використовував NMake, Make, Ant, Rake, NAnt та MSBuild для нетривіальних побудов (у такому порядку). Моя улюблена - MSBuild, руки вниз (і я не віддаю перевагу тому, що "саме цим користується Visual Studio"). IMHO, це дуже недооцінений інструмент побудови.
Я б порівняв NAnt проти MSBuild до різниці між процедурним та функціональним програмуванням. NAnt досить простий, і ви отримуєте-що-що-ви бачите. MSBuild, з іншого боку, вимагає трохи більше роздумів. Крива навчання крутіша. Але як тільки ви «отримаєте це», ви зможете зробити з ним деякі дивовижні речі.
Тому я рекомендую подивитися на MSBuild, якщо ви також орієнтуєтесь на функціональне або логічне програмування стилів - якщо ви готові вкласти трохи часу та зусиль, перш ніж побачити відчутні результати (звичайно, я також твердо вірю, що інвестиція в підсумку окупиться, і ви може робити більш потужні речі ефективніше).
Особисто я використовую обоє - для одного проекту.
MSBuild чудово створює рішення та проекти Visual Studio - саме для цього він створений.
NAnt легше редагувати вручну, на мою думку - особливо якщо ви вже знаєте Мураш. NAnt може викликати MSBuild дуже легко за допомогою NAntContrib. Отже, я розробив сценарій NAnt, щоб виконувати такі речі, як копіювання вбудованих файлів, очищення тощо - і закликаю MSBuild зробити фактичну частину "перетворити мій вихідний код C # на збірки".
Якщо ви хочете прикладу цього, подивіться мій файл збірки буферів протоколів . (Я б не стверджував, що це казковий сценарій NAnt, але він робить свою роботу.)
NAnt має більше функцій, але MSBuild має набагато кращу фундаментальну структуру (елемент метаданих порід), що робить його набагато простіше будувати багаторазові сценарії MSBuild.
MSBuild потребує певного часу, щоб зрозуміти, але колись ти це робиш, це дуже приємно.
Навчальні матеріали:
KISS = Використовуйте MSBuild.
Навіщо додавати щось інше в суміш, коли у вас є щось, що зробить розумну роботу поза коробкою? Коли прибув MSBuild, НАнт помер. І Mono матиме реалізацію MSBuild, ( xbuild ).
DRY = Використовуйте MSBuild.
Запитайте себе, що ви хочете отримати від системи складання? Я хочу створити систему побудови, яку також використовує моя IDE, а не підтримка двох різних конфігурацій.
Особисто я хотів би почути деякі реальні аргументи щодо NAnt, тому що я просто не можу придумати жодного, який насправді затримує воду.
Одне, що я помітив у кількох афішах, - це редагування файлів .csproj (або .vbproj тощо).
MSBuild дозволяє налаштувати ці файли. * Proj за допомогою файлів .user. Якщо у мене є проект під назвою MyCreativelyNamedProject.csproj і хочете налаштувати завдання MSBuild всередині нього, я можу створити файл під назвою MyCreativelyNamedProject.csproj.user і використовувати CustomBeforeMicrosoftCommonTargets та CustomAfterMicrosoftCommonTargets для налаштування цих файлів.
Крім того, і NAnt, і MSBuild можна налаштувати під вміст серця за допомогою спеціальних завдань MSBuild та через розширення NantContrib.
Отже, використання NAnt або MSBuild дійсно зводиться до знайомства:
Варто також додати, що MSBuild майже гарантовано працює з усіма новими версіями .NET та Visual Studio, як тільки вони будуть випущені, тоді як NAnt може мати деякий відставання.
Я використовую обидва в тому, що мої сценарії NAnt називають MSBuild. Моя основна причина перебування з NAnt - ізоляція . Дозвольте мені пояснити, чому я вважаю це важливим:
Додавання залежностей до вашого проекту. Файл збірки NAnt чужий для Visual Studio (в моєму випадку я вважаю це професіоналом), тому Visual Studio не намагається нічого з цим робити. Завдання MSBuild вбудовані як частина рішення і можуть посилатися на інші завдання MSBuild. Я отримав вихідний код від когось іншого, щоб дізнатися, що я не міг створити, оскільки завдання спільноти MSBuild не були встановлені. Що мене особливо засмучує, це те, що Visual Studio просто не збирався і викинув купу помилок, які змусили втратити час налагодження. Це, незважаючи на те, що запитувана збірка могла піти вперед (як, наприклад, збірка налагодження) без деяких додаткових завдань MSBuild. Якщо коротко: мені не подобається додавати залежності до мого проекту, якщо я можу його уникнути .
Я не довіряю Visual Studio, наскільки я міг би кинути її розробників. Це пов’язано з першими днями роботи Visual Studio, коли це могло б розправити мій HTML. Наприклад, я досі не використовую дизайнера (на нещодавній конференції я виявив, що колеги зробили те саме). Я виявив, що Visual Studio може викрутити залежності та номери версій у файлі DLL (я не можу це повторити, але це сталося в проекті послідовно і спричинило багато горя та втраченого часу). Я вдався до процедури збирання, яка використовує Visual Studio для побудови лише в режимі налагодження. Для виробництва я використовую NAnt, щоб контролювати все зовні . Visual Studio просто не може більше перешкоджати, якщо я будую за допомогою NAnt.
PS: Я веб-розробник і не займаюся розробкою Windows Forms.
Хоча я не дуже знайомий з MsBuild, я маю враження, що деякі ключові відмінності з обох сторін можуть бути доповнені доповненнями:
Нещодавно мені довелося будувати проект Silverlight у Нанті. Я виявив, що життя буде простішим, якби я щойно зробив це з MsBuild - я в кінцевому підсумку викликав завдання MsBuild із сценарію Nant, тому, гадаю, це не надто звичайне, щоб поєднувати та поєднувати два.
Крім того, я думаю, це буде питання особистих уподобань - очевидно, ви можете керувати деякими / більшістю функціональності MsBuild з Visual Studio, якщо це ваша справа. Нант здається більш гнучким і краще підходить, якщо ви віддаєте перевагу писати сценарії вручну, а якщо ви приїжджаєте зі світу Java, ви, швидше за все, будете з ним вдома.
Я закінчив використовувати обоє. Під час перепроектування нашої системи побудови я зіткнувся з складною проблемою. А саме, я не міг позбутися .vcproj (та сім'ї), тому що всі ми використовували VS для оновлення файлів проекту, налаштувань та конфігурацій. Тож без величезного дублювання та схильності до помилок ми не змогли базувати нашу систему побудови на новому наборі файлів.
З цієї причини я вирішив зберегти "proj" файли VS та використовувати MSBuild (це файли MSBuild, принаймні VS2005 та VS2008 використовують файли проекту MSBuild). Для всього іншого (спеціальна конфігурація, тестування одиниць, упаковка, підготовка документації ...) я використовував NAnt.
Для постійної інтеграції я використовував CruiseControl. Отже, у нас були сценарії CC, які запускали завдання NAnt, які для побудови використовували MSBuild.
Останнє зауваження: MSBuild НЕ підтримує програми налаштування! Таким чином, ви застрягли в тому, щоб зателефонувати на DevEnv.com або скористатися Visual Studio безпосередньо. Так я і закінчився, але я встановив проект налаштування за замовчуванням від усіх конфігурацій рішення, оскільки розробникам зазвичай не потрібно їх будувати, і якщо вони будуть, вони можуть вручну вибрати для їх створення.
Нещодавно я перейшов з NAnt на MSBuild через його здатність будувати VS-рішення. Я все ще використовую NAnt зрідка, хоча.
Ви також можете перевірити MSBuild Завдання спільноти, які схожі на NAntContrib.
Документація та підручники, доступні для NAnt, полегшують навчання навчанню створення сценаріїв з NAnt. Як тільки я отримав вивірку NAnt і створив сценарії збірки, я почав перекладати ці знання в MSBuild (я зробив X в NAnt, як мені зробити X в MSBuild?). Документація Microsoft зазвичай передбачає досить високий рівень знань, перш ніж вона стане корисною.
Причина переходу з NAnt на MSBuild полягає в тому, що MSBuild є більш поточним. На жаль, останній реліз NAnt був у грудні 2007 року, тоді як MSBuild 4.0 (.NET 4.0) не за горами. Схоже, проект NAnt загинув.
Якщо ви знайдете гарну документацію для того, хто тільки починає вчитися створювати сценарії збірки за допомогою MSBuild, тоді пропустіть NAnt і перейдіть прямо до MSBuild. Якщо NAnt коли-небудь вийде з новим випуском, то я б подумав дотримуватися NAnt, але вони зараз відстають.
Ми використовуємо і те, і інше. NAnt несе відповідальність за всі "сценарії", такі як копіювання, розміщення на IIS , створення пакетів, а MSBuild відповідає за створення рішення. Тоді ми можемо уникнути проблем із непідтримуваною .NET 4.0 новою версією NAnt.
NAnt також більш масштабований. Якщо ми хочемо перенести сценарії розгортання на виробничі сервери, ми лише скопіюємо файл збірки та встановимо належну версію .NET - проблем з Visual Studio немає з файлами csproj :)
YDeliver by Manoj - це структура побудови, побудована на версії PSake. Він має багатий набір бібліотечних функцій, здатність визначати робочі процеси, і ми використовували його для доставки більше шести підприємств для виробництва.
Використовуйте його спільно з TeamCity , CruiseControl або будь-чим, що може запускати PowerShell .
Ми використовуємо FlubuCore. Це бібліотека C # з відкритим кодом для створення проектів та виконання сценаріїв розгортання за допомогою коду C #.
Простий приклад використання флюбу:
protected override void ConfigureTargets(ITaskContext session)
{
var compile = session.CreateTarget("compile")
.SetDescription("Compiles the solution.")
.AddTask(x => x.CompileSolutionTask())
.DependsOn("generate.commonassinfo");
}Ви можете знайти більше інформації про flubu та про те, як розпочати роботу тут: вибір-для-побудови-інструмента-msbuild-nant-або-щось ще