Стоит ли переходить с nant на msbuild?

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

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

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

Ответов (18)

Решение

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

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

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

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

Я использую Nant, и мне это нравится. Я использовал MSBuild и возненавидел его из-за следующих причин:

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

  2. Типы элементов для выполнения файловых операций слишком сложны для понимания. Вы можете заставить Nant делать то же самое, но гораздо проще и прямо (мне пришлось создать список ItemType, а затем перейти к файловым операциям).

  3. В MsBuild вы должны создать свою собственную DLL-библиотеку задач, в Nant вы можете это сделать или можете встроить код C# в свой скрипт, поэтому его намного проще продвигать и просто создавать весь проект.

  4. Nant работает с Net1.1, MsBuild - нет.

  5. Чтобы установить nant, я могу даже разархивировать его и найти в собственном репозитории для его запуска. Установить MsBuild намного сложнее, так как это зависит от многих вещей из Visual Studio и т. Д. (Возможно, я здесь ошибаюсь, но, похоже, это правда).

Ну это мои мнения ...

@Brad Leach

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

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

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

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

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

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

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

Изменить: похоже, Nant теперь создает приложения .NET 3.5.

Я использую MSBuild вместе с Nant, потому что текущая версия Nant еще не может компилировать приложения .NET 3.5 (то же самое было верно, когда .NET 2.0 только вышла).

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

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

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

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

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

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

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

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

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

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

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

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

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

На самом деле я все еще пытаюсь разобраться в этом вопросе, но здесь есть один большой бонус для MSBuild: использование того же файла сборки для локальной непрерывной интеграции путем прямого вызова msbuild.exe, а также возможность использования VSTS на стороне сервера. интеграция с одним и тем же файлом сборки (хотя, скорее всего, с разными свойствами / настройками).

т.е. по сравнению с поддержкой TeamCity сценариев MSBuild, VSTS поддерживает только сценарии MSBuild! Раньше я обходился с этим, выполняя NAnt из MSBuild; Я видел, как другие рекомендуют эту практику, а также обратную, но мне она кажется бессмысленной, поэтому я стараюсь этого не делать, если могу этого избежать. Поэтому, когда вы используете «полный стек Microsoft» (VSTS и TFS), я бы посоветовал просто придерживаться сценариев MSBuild.

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

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

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

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

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

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

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

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

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

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

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

Не вижу смысла переключаться. Сам MsBuild блокирует вас в используемом вами фреймворке. Если вы используете NAnt, вы можете использовать его во многих фреймворках и использовать оболочку для msbuild, чтобы фактически выполнить задачу сборки за вас.

В этом отношении я поклонник NAnt, потому что он немного отделяет вас от фреймворка.

Я создал фреймворк, который объединяет соглашения в автоматизированные сборки, и построил его на NAnt. Он называется UppercuT, и это безумно простой в использовании фреймворк для сборки.

Автоматизированная сборка - это просто: (1) имя решения, (2) путь к системе управления версиями, (3) название компании для большинства проектов!

http://code.google.com/p/uppercut/

Вот несколько хороших объяснений: UppercuT

MSBuild, интегрированный с Visual Studio, снижает затруднения программистов при использовании системы сборки. В основном это сводится к тому, что им нужно только пойти «Сборка решения», и все это работает, вместо того, чтобы использовать пользовательские шаги сборки и другие подобные вещи, или, что еще хуже, заставлять разработчиков строить, запуская какой-то внешний скрипт.

Сейчас я в основном предпочитаю MSBuild NAnt, потому что это проще. Конечно, у NAnt намного больше возможностей, он более мощный и т. Д., Но он может быстро выйти из-под контроля. Если вы и ваши инженеры по сборке достаточно дисциплинированы, чтобы делать сценарии NAnt простыми, тогда все в порядке. Однако я видел слишком много систем, основанных на NAnt, которые уходили на юг до точки, когда никто больше не понимал, что они делают, и нет никакого реального способа отладить это, кроме как сделать эквивалент старого доброго printf. В тот момент, когда вы начинаете использовать какой-либо оператор if / else или цикл for, вот где, IMHO, он начинает пахнуть.

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

Единственная проблема с MSBuild - это не очень случайная ошибка (особенно в первой версии) или неясное (хотя и задокументированное) поведение. И, если это действительно беспокоит вас, привязанность к Microsoft.

Я перешел с NANT на MSBuild. Проект работает в .Net 4.0.

Мой опыт в Нанте был хорошим. Проект вроде умер. А когда появился .Net 4.0, пришло время переоценить процесс сборки.

С тех пор, как Nant был выпущен в последний раз, MSBuild претворяется в жизнь. На данный момент MSBuild - лучший вариант. Удобен в использовании, имеет множество расширений. Я переписал свои скрипты Nant за полтора дня. Сценарий MSBuild составляет 1/3 размера сценариев Nant.

Большая часть работы в сценарии Nant заключалась в настройке различных сред. В MsBuild / .Net 4.0 он встроен.