NAnt или MSBuild, какой выбрать и когда?

Question

Я знаю, что есть другие вопросы, связанные с переполнением стека NAnt и MSBuild , но я не смог найти прямого сравнения между ними, и вот вопрос.

Когда нужно выбирать NAnt вместо MSBuild? Какой из них лучше для чего? Подходит ли NAnt для проектов дома / с открытым исходным кодом и MSBuild для рабочих проектов? Какой опыт у любого из двух?

Answer 1

Я провел аналогичное расследование на этой неделе. Вот что я смог определить:

NAnt:

• Кроссплатформенность (поддерживает Linux / Mono). Это может быть удобно для установки веб-сайта для нескольких целей (например, Linux Apache и Windows IIS), например.
• 95% схожи по синтаксису с Ant (легко для текущих пользователей Ant или сборщиков Java)
• Интеграция с NUnit для запуска модульных тестов в составе сборки и с NDoc для документации по продукту.

MSBuild:

• Встроенный в .NET.
• Интегрировано с Visual Studio
• Легко начать работу с MSBuild в Visual Studio - все это за кадром. Если вы хотите углубиться, вы можете отредактировать файлы вручную.

Субъективные различия: (YMMV) * ​​1030 *

• Документация NAnt немного проще. Например, Справочник задач MSBuild содержит список «Csc Task - Описывает задачу Csc и ее параметры» (спасибо за «помощь»?), А NAnt Task Reference"csc - Компилирует программы на C #. " ОБНОВЛЕНИЕ: Я заметил, что документация MSBuild была улучшена и теперь намного лучше (вероятно, на уровне NAnt).
• Нелегко понять, как редактировать исходный код сценария сборки (файл *. * Proj) непосредственно из Visual Studio. С помощью NAnt Visual Studio обрабатывает скрипт .build как файл XML.
• По-видимому, в Visual Studio проекты веб-приложений по умолчанию не получают файл *. * Proj, поэтому мне было очень трудно понять, как даже запустить MSBuild на моем компьютере для создания сценария развертывания.
• NAnt не является встроенным в Visual Studio и должен быть добавлен либо с помощью надстройки, либо в качестве «внешнего инструмента». Это немного сложно настроить.
• (Правка :) Один из моих коллег поднял этот вопрос - если вы хотите настроить сборочную машину, используя CruiseControl для непрерывной интеграции, CruiseControl легко интегрируется с NAnt из коробки. ОБНОВЛЕНИЕ: CruiseControl также имеет задачу MSBuild .
• Пожалуйста, смотрите комментарии ниже для полного и актуального обсуждения субъективных различий.

Answer 2

Одним из главных преимуществ MSBuild для меня (на платформах Windows) является то, что он входит в состав самого .NET. Это означает, что на любой машине с Windows, на которой установлено обновление Windows, будет доступен MSBuild. Добавьте к этому тот факт, что компилятор C # также является частью самого .NET, и у вас есть платформа, которая может создавать проекты на чистых машинах. Не нужно устанавливать бегемот Visual Studio. NAnt, с другой стороны, должен быть явно установлен, прежде чем сборка может быть запущена.

Просто для записи, в прошлом я использовал NMake, Make, Ant, Rake, NAnt и MSBuild для нетривиальных сборок (в таком порядке). Мой любимый MSBuild, руки вниз (и я не одобряю его, потому что «это то, что Visual Studio использует»). ИМХО, это очень недооцененный инструмент для сборки.

Я бы сравнил NAnt и MSBuild с разницей между процедурным и функциональным программированием. NAnt довольно прост, и вы получите то, что видите. MSBuild, с другой стороны, требует немного больше мысли. Кривая обучения круче. Но как только вы «получите это», вы сможете делать с ним удивительные вещи.

Поэтому я бы порекомендовал взглянуть на MSBuild, если вы также стремитесь к программированию в функциональном или логическом стиле - если вы готовы потратить немного времени и усилий, прежде чем увидите ощутимые результаты (конечно, я также твердо верю, что в конечном итоге инвестиции окупятся вы можете делать более мощные вещи более эффективно).

Answer 3

Лично я использую оба - для одного проекта.

MSBuild отлично подходит для создания решений и проектов Visual Studio - для этого он и создан.

NAnt легче редактировать вручную, на мой взгляд, особенно если вы уже знаете Ant. NAnt может легко вызвать MSBuild с помощью NAntContrib. Поэтому я вручную создаю сценарий NAnt для выполнения таких задач, как копирование встроенных файлов, очистка и т. Д., И вызываю MSBuild, чтобы выполнить фактическую часть «превращение моего исходного кода C # в сборки».

Если вам нужен пример этого, посмотрите на мой файл сборки буферов протокола . (Я бы не стал утверждать, что это невероятный сценарий NAnt, но он справляется со своей работой.)

Answer 4

NAnt имеет больше функций из коробки, но MSBuild имеет гораздо лучшую фундаментальную структуру (метаданные элемента), которая значительно упрощает создание повторно используемых скриптов MSBuild. *

MSBuild требуется время, чтобы понять, но как только вы это сделаете, это очень приятно.

Учебные материалы:

• Внутри Microsoft Build Engine: использование MSBuild и Team Foundation Build
  Сайед Ибрагим Хашими (январь 2009 г.)
• Развертывание приложений .NET: изучение MSBuild и ClickOnce от Sayed
  Ю. Хашими (сентябрь 2008 г.)

Answer 5

KISS = Использовать MSBuild.

Зачем добавлять что-то еще в микс, если у вас есть что-то, что будет делать разумную работу из коробки? Когда MSBuild прибыл, NAnt умер. И Mono будет иметь реализацию MSBuild ( xbuild ).

DRY = Использовать MSBuild.

Спросите себя, что вы хотите от системы сборки? Мне нужна система сборки, которая также используется моей IDE вместо двух разных конфигураций.

Лично я хотел бы услышать некоторые реальные аргументы для NAnt, потому что я просто не могу думать ни о каких, которые действительно держат воду.

Answer 6

Одна вещь, которую я заметил в нескольких постерах, касалась необходимости редактировать файлы .csproj (или .vbproj и т. Д.) Вручную.

MSBuild позволяет настраивать эти файлы. * Proj с помощью файлов .user. Если у меня есть проект с именем MyCreativelyNamedProject.csproj и я хочу настроить внутри него задачи MSBuild, я могу создать файл с именем MyCreativelyNamedProject.csproj.user и использовать CustomBeforeMicrosoftCommonTargets и CustomAfterMicrosoftCommonTargets для настройки этих файлов.

Кроме того, как NAnt, так и MSBuild можно настроить в соответствии с содержанием сердца с помощью пользовательских задач MSBuild и расширений NantContrib.

Итак, использование NAnt или MSBuild действительно сводится к знакомству:

• Если вы уже знакомы с Ant, используйте NAnt. Кривая обучения будет очень простой.
• Если вы не знакомы ни с одним из этих инструментов, MSBuild уже интегрирован с Visual Studio и не требует дополнительных инструментов.

Стоит также добавить, что MSBuild в значительной степени гарантированно будет работать со всеми новыми версиями .NET и Visual Studio, как только они будут выпущены, тогда как NAnt может иметь некоторую задержку.

Answer 7

Я использую оба в том, что мои NAnt скрипты вызывают MSBuild. Моя главная причина остаться с NAnt - изоляция . Позвольте мне объяснить, почему я чувствую, что это важно:

1. Добавление зависимостей в ваш проект. Файл сборки NAnt чужд Visual Studio (в моем случае я считаю это про), поэтому Visual Studio не пытается ничего с ним поделать. Задачи MSBuild встроены в часть решения и могут ссылаться на другие задачи MSBuild. Я получил исходный код от кого-то другого только для того, чтобы выяснить, что я не смог собрать, потому что задачи сообщества MSBuild не были установлены. Что меня особенно огорчает, так это то, что Visual Studio просто не собиралась и выкидывала кучу ошибок, из-за которых я терял время на отладку. И это несмотря на то, что запрашиваемая сборка могла бы продолжаться (например, как отладочная сборка) без некоторых дополнительных возможностей задачи MSBuild. Короче говоря: Мне не нравится добавлять зависимости в мой проект, если я могу избежать этого .

2. Я не доверяю Visual Studio настолько, насколько я мог бы бросить ее команду разработчиков. Это относится к ранним временам Visual Studio, когда она уничтожала мой HTML. Я до сих пор не использую дизайнера, например (недавно на конференции я обнаружил, что коллеги сделали то же самое). Я обнаружил, что Visual Studio может испортить зависимости и номера версий в файле DLL (я не могу воспроизвести это, но это происходило последовательно в проекте и вызывало много горя и потерянного времени). Я прибег к процедуре сборки, которая использует Visual Studio для сборки только в режиме отладки. Для производства я использую NAnt, чтобы контролировать все извне . Visual Studio просто не может больше вмешиваться, если я строю с использованием NAnt.

PS: я веб-разработчик и не занимаюсь разработкой Windows Forms.

Answer 8

Хотя я не очень знаком с MsBuild, у меня сложилось впечатление, что некоторые ключевые различия с обеих сторон могут быть дополнены дополнениями:

• MsBuildTasks
• NantContrib

Недавно мне пришлось построить проект Silverlight в Нанте. Я обнаружил, что жизнь была бы проще, если бы я просто сделал это с MsBuild - в итоге я вызвал задачу MsBuild из скрипта Nant, так что я полагаю, что не слишком необычно смешивать и сопоставлять их.

Кроме того, я полагаю, что это будет вопрос личных предпочтений - очевидно, вы можете управлять некоторыми / большинством функций MsBuild из Visual Studio, если это ваша задача. Nant кажется более гибким и более подходящим, если вы предпочитаете писать сценарии вручную, и если вы приехали из мира Java, вы, вероятно, будете чувствовать себя как дома.

Answer 9

Я закончил тем, что использовал оба. При перепроектировании нашей системы сборки я столкнулся с непростой проблемой. А именно, я не смог избавиться от .vcproj (и семейства), потому что мы все использовали VS для обновления файлов проекта, настроек и конфигураций. Поэтому без огромного дублирования и подверженного ошибкам процесса мы не могли бы основать нашу систему сборки на новом наборе файлов.

По этой причине я решил сохранить файлы 'proj' VS и использовать MSBuild (это файлы MSBuild, по крайней мере VS2005 и VS2008 используют файлы проекта MSBuild). Для всего остального (пользовательская конфигурация, модульное тестирование, упаковка, подготовка документации ...) я использовал NAnt.

Для непрерывной интеграции я использовал CruiseControl. Итак, у нас были сценарии CC, которые запускали задания NAnt, которые для сборки использовали MSBuild.

Последнее замечание: MSBuild НЕ поддерживает проекты установки! Таким образом, вы застряли с вызовом DevEnv.com или с использованием Visual Studio напрямую. Это то, что я в итоге сделал, но я по умолчанию отключил проект установки из всех конфигураций решения, так как разработчикам обычно не нужно их создавать, и если они это сделают, они могут выбрать их вручную.

Answer 10

Документация и учебные пособия, доступные для NAnt, облегчают изучение сценариев сборки с помощью NAnt. Как только я освоил NAnt и создал сценарии сборки, я начал переводить эти знания в MSBuild (я сделал X в NAnt, как мне сделать X в MSBuild?). Документация Microsoft обычно предполагает довольно высокий уровень знаний, прежде чем она будет полезна.

Причина переключения с NAnt на MSBuild заключается в том, что MSBuild более актуален. К сожалению, последний выпуск NAnt был 8 декабря 2007 года, а MSBuild 4.0 (.NET 4.0) не за горами. Похоже, проект NAnt умер.

Если вы найдете хорошую документацию для того, кто только начинает изучать создание сценариев сборки с использованием MSBuild, пропустите NAnt и перейдите прямо к MSBuild. Если NAnt когда-нибудь выпустит новый релиз, то я бы решил остаться с NAnt, но сейчас они отстают.