Должен ли я перейти с nant на msbuild?

StackOverflow https://stackoverflow.com/questions/10634

Вопрос

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

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

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

Это было полезно?

Решение

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Брэд Лич

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Несколько хороших объяснений здесь: Апперкот

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

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

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

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

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

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

Со времени последнего выпуска Nant MSBuild значительно улучшился.На этом этапе лучше всего использовать MSBuild.Он прост в использовании, имеет множество расширений.Я переписал свои сценарии Нанта за полтора дня.Размер сценария MSBuild составляет 1/3 размера сценариев Nant.

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

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

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

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

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

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

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

  4. Нант работает с Net1.1, MsBuild — нет.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top