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

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

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

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

14.08.2008 03:36:54
webwesen 16.01.2010 17:00:46
webwesen обнаружил рекурсивную дыру в этой вселенной, разместив ссылку на вопрос, которого не существовало, не должно ли быть иначе?
DevelopingChris 18.01.2010 03:35:05
18 ОТВЕТОВ
РЕШЕНИЕ

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

Также, как отмечает Рубен, в CodePlex есть задачи Задачи SDC .

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

31
14.08.2009 21:25:38
Также есть задачи SDC. И книга Хашими.
Ruben Bartelink 14.08.2009 08:37:57

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

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

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

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

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

9
15.12.2008 18:39:59
NANT сейчас создает приложения .net 3.5.
Autodidact 30.11.2008 08:07:19

@Brad Leach

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

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

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

1
14.08.2008 03:49:42

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

0
14.08.2008 03:53:09

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

0
14.08.2008 04:06:00
У cruisecontrol.net есть задачи для nant и msbuild из коробки
Hamish Smith 15.12.2008 18:45:30

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

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

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

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

1
14.08.2008 06:07:42

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

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

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

12
15.08.2008 14:39:02

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

27
15.08.2008 14:49:46
+1 MSBuild имеет свое место, но NAnt гораздо мощнее. Я не нашел веских причин для переключения, особенно когда в NAntContrib существует задача <msbuild>.
Scott Saad 1.12.2008 15:58:50
Я широко использовал оба этих метода, хотя мне не нравилось, как Microsoft в основном копировал NAnt, MSBuild проще разрабатывать пользовательские задачи, и если вы объединяете задачи сообщества MSBuild с пакетом расширений MSBuild, то у вас есть широкий набор инструментов. MSBuild побеждает, потому что он интегрирован в проекты MS.
si618 29.03.2009 00:05:56
Si, ты не прав. 1) Пользовательские задачи в NANT настолько просты, насколько это возможно - подкласс Задачи 2) NANT имеет NANTContrib, а также намного больше поддержки сообщества, чем MSBuild 3) Я интегрирую NANT в свои проекты MS, записывая пакетный файл для запуска NANT.exe. Это сборка, а не ракетная операция.
Jim 29.03.2009 21:04:46
MSBuild отличается, но его так же легко и мощно использовать, как и Nant, особенно с пакетом расширений. Также полезно знать инструмент, который запускает ваш файл csproj для начала ... и вы можете погрузиться в изменение того, как сборки работают для всех разработчиков (путем изменения csproj) и того, как это происходит в каждой сборке. Это также еще одна вещь, которую нужно установить, и nant кажется довольно мертвым на данный момент.
Andy 16.07.2012 15:25:32

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

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

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

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

1
15.08.2008 14:55:25
Вы можете настроить msbuild для создания отдельных сборок в одном проекте. По умолчанию это не то, что делает VS2008, но это не сложно сделать.
Cheeso 28.03.2009 23:29:30
эти вещи легко выполнимы с msbuild.
justin.m.chase 21.07.2009 22:26:02

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

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

1
30.11.2008 07:41:58

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

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

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

2
4.12.2008 07:37:23

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

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

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

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

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

3
17.02.2009 04:20:01

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

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

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

1
28.03.2009 23:58:04
самый убедительный аргумент, который я слышал о msbuild - это clickonce. Тем не менее, я нахожу clickonce принципиально проблематичным, поэтому избегаю его и использую это как хороший аргумент против msbuild.
DevelopingChris 29.03.2009 19:21:19
Почему ClickOnce, являющийся пробломатическим (не то, чтобы я с этим согласен), имел какое-то отношение к MSBuild?
Sayed Ibrahim Hashimi 29.08.2009 18:25:18
  • Не переключайтесь, если у вас нет очень убедительной причины (по крайней мере).
  • NAnt является открытым исходным кодом, и если бы не было, я бы не смог настроить нашу систему сборки, MSBuild - нет.
  • NAnt может легко запустить MSBuild, я не уверен в обратном.
  • Скрипты MSBuild уже написаны для вас, если вы используете VS2005 или новее (файлы проекта являются файлами MSBuild.)
  • Если вы используете NAnt, и вы используете VS для редактирования файлов проекта, настроек и конфигураций, вам придется написать конвертер / инструмент синхронизации для обновления ваших файлов NAnt из файлов проекта VS.
2
11.04.2009 11:20:35

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

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

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

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

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

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

1
18.05.2009 15:03:31

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

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

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

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

1
16.10.2009 17:36:47

Я переключился с NANT на MSBuild. Проект работает в .Net 4.0.

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

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

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

1
11.06.2010 14:52:13

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

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

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

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

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

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

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

0
30.07.2012 17:21:25
MSBuild 4.0 поддерживает встроенные задачи - см. Msdn.microsoft.com/en-us/library/dd722601.aspx .
BCran 30.12.2012 20:46:08
Хорошо, но это в VS2012. Я говорю о приложении VS2003. Меня так расстраивает, что MS заставляет вас обновить весь стек разработки, чтобы получить новые функции. Если бы они могли просто выпустить каждую вещь отдельно, это было бы гораздо менее болезненным.
Kat Lim Ruiz 20.02.2013 17:05:31