Должен ли я перейти от Nant к MSBuild?

Question

В настоящее время я использую nant, ccnet (круиз-контроль), svn, mbunit. Я использую msbuild для создания sln только потому, что его было проще выложить.

Есть ли какие-либо преимущества в переключении всего сценария сборки на MSBuild? Мне нужно иметь возможность запускать тесты, тесты в стиле watir, xcopy deploy. Это проще?

Обновление: какие-нибудь убедительные функции, которые заставили бы меня перейти от nant к msbuild?

Answer 1

Мне нравится MSBuild. Одна из причин заключается в том, что файлы .csproj являются файлами msbuild, а сборка в VS аналогична сборке в командной строке. Другая причина - хорошая поддержка от TeamCity, который используется CI-сервером. Если вы начинаете использовать MSBuild и хотите сделать больше пользовательских вещей в процессе сборки, получите Задачи сообщества MSBuild . Они дают вам кучу приятных дополнительных заданий. Я не пользуюсь NAnt уже несколько лет и не жалею об этом.

Кроме того, как упоминает Рубен, в CodePlex есть задачи SDC .

Для еще большего удовольствия в CodePlex имеется пакет расширений MSBuild, включающий задачу Twitter.

Answer 2

Мой совет как раз наоборот - избегайте MSBuild, как чума. NANT намного проще настроить вашу сборку для автоматического тестирования, развертывания в нескольких производственных средах, интеграции с cruisecontrol для начальной среды, интеграции с контролем версий. Мы прошли через большую боль с TFS / MSBuild (с использованием TFSDeployer, пользовательских скриптов PowerShell и т. Д.), Чтобы заставить его делать то, что мы могли делать с NANT из коробки. Не трать свое время.

Answer 3

Самая веская причина использовать MSBuild (по крайней мере, в .NET 3.5 и более поздних версиях) - механизм сборки может собираться одновременно.

Это означает, что в ваших сборках значительно ускорилось использование нескольких ядер / процессоров.

До 3.5 MSBuild не делала параллельные сборки.

Answer 4

Я чувствую, что MSBuild и Nant довольно сопоставимы. Если вы используете один из них, я бы не стал переключаться между ними, если в выбранном вами продукте отсутствовала неотразимая функция.

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

Надеюсь, это поможет!

Редактировать: @ChanChan - @Jon упоминает, что Nant не создает приложения .NET 3.5. Этого может быть достаточно, чтобы либо изменить, либо хотя бы использовать их параллельно. Поскольку я больше ориентируюсь на MSBuild, я, вероятно, не самый осведомленный человек, чтобы осветить любые другие демонстраторы с любой из технологий.

Редактировать: Похоже, Nant теперь создает приложения .NET 3.5.

Answer 5

NAnt существует дольше и является значительно более зрелым продуктом, а также IMO более простым в использовании. Существует множество ноу-хау сообщества, к которому можно обратиться, и оно также кроссплатформенное, если вы заинтересованы в создании приложений, которые могут работать под Mono, а также .NET и Silverlight. Из коробки это делает намного больше, чем MSBuild. О да, и вы можете позвонить в MSBuild из NAnt (ОК, из NAntContrib): -)

С другой стороны, NAnt и его дочерний проект NAntContrib, похоже, застоялись, а последнее обновление было в конце 2007 года.

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

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

Вывод? Если вы работаете с существующими сценариями NAnt, придерживайтесь их, это не стоит хлопот по переносу. Если вы начинаете новый проект и чувствуете себя авантюрным, тогда попробуйте MSBuild.

Answer 6

• Не переключайтесь, если у вас нет очень убедительной причины (по крайней мере).
• NAnt с открытым исходным кодом, и если бы это было не так, я бы не смог настроить нашу систему сборки, MSBuild - нет.
• NAnt может легко запустить MSBuild, я не уверен в обратном.
• Скрипты MSBuild уже написаны для вас, если вы используете VS2005 или новее (файлы проекта MSBuild.)
• Если вы используете NAnt и используете VS для редактирования файлов проекта, настроек и конфигураций, вам придется написать инструмент преобразования / синхронизации для обновления файлов NAnt из файлов проекта VS.

Answer 7

Мы также перешли с nant на msbuild. Если ваша сборка довольно стандартная, то у вас не будет особых проблем с ее настройкой, но если у вас много конкретных задач сборки, вам придется писать собственные задачи сборки ms, поскольку для msbuild гораздо меньше пользовательских задач.

Если вы хотите отобразить приемлемые результаты сборки, вам придется связываться с пользовательскими регистраторами и т. Д. Вся сборка команды не так хороша, как nant.

Но реальным преимуществом является интеграция со службами контроля версий TFS и службами отчетов. Если вы не используете TFS в качестве системы контроля версий, это того не стоит.

Answer 8

@ Брэд Лич

Как правило, я бы не стал переключаться между ними, если бы не было убедительной функции, которой не было

Каковы веские причины использовать msbuild? есть ли минусы?

Пока я получаю довольно хороший ответ "нет, не беспокойся".

Answer 9

Основная причина, по которой я все еще использую nAnt вместо msbuild для своих автоматических сборок, заключается в том, что у меня более детальный контроль над сборками. Благодаря тому, что msbuild использует csproj, имеет свой файл сборки, весь исходный код в этом проекте скомпилирован в одну сборку. Что заставляет меня иметь много проектов в моем решении для больших проектов, где я разделяю логику. Хорошо, с помощью nant я могу организовать свою сборку, где я могу собрать то, что я хочу, в несколько сборок из одного проекта.

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

Однако я использую и nant, и msbuild вместе для некоторых задач сборки, таких как сборка приложений WPF. Намного проще скомпилировать приложение WPF с целью msbuild в nant.

Чтобы закончить это, и смысл моего ответа в том, что мне нравится использовать их бок о бок, но когда я использую msbuild в этой конфигурации, это обычно для прямой компиляции, а не выполнения каких-либо задач автоматизации сборки, таких как копирование файлов в каталог, генерирующий справочную документацию или выполняющий мои модульные тесты, например.

Answer 10

Я думаю, что они относительно сопоставимы как по функциям, так и по простоте использования. Начиная с C #, я считаю, что с msbuild работать легче, чем с nants, хотя вряд ли это является веской причиной для перехода.

Что именно Нант не делает для вас? Или вы просто надеетесь, что есть какая-то интересная функция, которую вы можете упустить? :)

Одна очень приятная вещь в C # заключается в том, что если у вас есть .net framework, у вас есть все необходимое для запуска msbuild. Это фантастика, когда вы работаете над большими командами / проектами и у вас есть человек / аппаратный оборот.

Лично я предпочитаю SCons обоим из них:)