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

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

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

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

NAnt:

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

MSBuild:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СУХОЙ = использовать MSBuild.

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

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

Одна вещь, которую я заметил в нескольких постерах, была о том, что пришлось вручную редактировать файлы .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 может иметь некоторую задержку.

Я использую оба в том, что мои сценарии 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.

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

• MsBuildTasks
• NantContrib

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

Кроме того, я полагаю, что это будет вопрос личных предпочтений - очевидно, вы можете управлять некоторыми / большей частью функциональности MsBuild из Visual Studio, если это ваша задача. Nant кажется более гибким и более подходящим, если вы предпочитаете писать сценарии вручную, и если вы приехали из мира 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 был 8 декабря 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 от Manoj - это фреймворк для сборки, построенный на основе PSake. Он имеет богатый набор библиотечных функций, возможность определять рабочие процессы, и мы использовали его для доставки более шести корпоративных проектов в производство.

Используйте его вместе с TeamCity , CruiseControl или любым другим , что может запускать PowerShell .

Мы используем FlubuCore. Это библиотека C # с открытым исходным кодом для построения проектов и выполнения сценариев развертывания с использованием кода C #.

Простой пример того, как используется flubu:

protected override void ConfigureTargets(ITaskContext session)
{           

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

Вы можете найти больше информации о flubu и о том, как начать работу здесь: choice-for-build-tool-msbuild-nant-или-что-то еще