В настоящее время я использую nant, ccnet (круиз-контроль), svn, mbunit. Я использую msbuild для выполнения моей сборки sln только потому, что ее проще было выложить.
Есть ли какие-либо преимущества для переключения всей сборки script на MSBuild? Мне нужно иметь возможность запускать тесты, тесты стиля watir, развертывание xcopy. Это проще?
Обновление: любые неотразимые функции, которые могли бы заставить меня перейти от nant к msbuild?
Мне нравится MSBuild. Одна из причин заключается в том, что файлы .csproj являются файлами msbuild, а построение в VS - это как построение в командной строке. Другая причина - хорошая поддержка TeamCity, которая является сервером CI, который я использовал. Если вы начнете использовать MSBuild и хотите сделать больше пользовательских вещей в процессе сборки, откройте Задачи сообщества MSBuild. Они дают вам кучу приятных дополнительных задач. Я не использовал NAnt уже несколько лет, и я не пожалел об этом.
Кроме того, как упоминает Рубен, в CodePlex есть задачи Задачи SDC.
Для еще большей забавы есть MSBuild Extension Pack на CodePlex, который включает в себя задачу twitter.
Мой совет - это все наоборот: избегайте MSBuild, как чума. NANT намного проще настроить свою сборку для автоматического тестирования, развертывания в нескольких производственных средах, интегрировать с cruisecontrol для среды ввода, интегрироваться с источником управления. Мы столкнулись с такой болью с помощью TFS/MSBuild (используя TFSDeployer, пользовательские сценарии powershell и т.д.), Чтобы заставить его делать то, что мы могли сделать с NANT из коробки. Не тратьте впустую свое время.
Самая убедительная причина использования MSBuild (по крайней мере, в .NET 3.5 и выше) - механизм сборки может создавать одновременно.
Это означает, что огромная скорость в ваших сборках у вас есть несколько ядер/процессоров.
До версии 3.5 MSBuild не выполнял параллельные сборки.
Я чувствую, что MSBuild и Nant довольно сопоставимы. Если вы используете один из них, я обычно не переключался между ними, если в выбранном вами продукте не было убедительной функции.
Я лично использую MSBuild для любого нового проекта, но ваш пробег может отличаться.
Надеюсь, что это поможет!
Изменить: @ChanChan - @Jon упоминает, что Nant не создает приложения .NET 3.5. Этого может быть достаточно, чтобы либо изменить, либо, по крайней мере, использовать их параллельно. Поскольку я больше перешел к MSBuild, я, вероятно, не самый информированный человек, чтобы выделить любые другие шоу-студии с любой технологией.
Изменить: Похоже, что Nant теперь создает приложения .NET 3.5.
NAnt работает дольше и является значительно более зрелым продуктом, а также IMO проще в использовании. Существует много ноу-хау сообщества, к которому нужно подключиться, и это также кросс-платформенный, если вы заинтересованы в создании приложений, которые могут работать под Mono, а также .NET и Silverlight. Из коробки это намного больше, чем MSBuild. О да, и вы можете вызвать MSBuild из NAnt (OK, из NAntContrib): -)
С отрицательной стороны NAnt и его дочерний проект NAntContrib, похоже, зашли в тупик, причем последнее обновление было в конце 2007 года.
Основными преимуществами, которые я вижу в MSBuild, является то, что он поставляется с .NET Framework, поэтому для него требуется меньше одного продукта; и происходит более активное развитие (хотя и в местах, где можно догнать более старый NAnt).
Лично я считаю, что его синтаксис немного сложнее подобрать, но тогда я уверен, что постоянное воздействие ti упростит ситуацию.
Вывод? Если вы работаете с существующими сценариями NAnt, придерживайтесь их, это не стоит хлопот портирования. Если вы начинаете новый проект, и вы чувствуете себя авантюристом, тогда дайте MSBuild пойти.
Мы также переключились с nant на msbuild. Если ваша сборка довольно стандартная, то у вас не будет много проблем с ее настройкой, но если у вас есть много конкретных задач сборки, вам придется писать собственные задачи сборки ms, поскольку для msbuild существует меньше пользовательских задач.
Если вы хотите отобразить разумные результаты сборки, вам придется столкнуться с пользовательскими регистраторами и т.д. Вся сборка команды не так зрелая, как у nant.
Но реальная выгода - это интеграция с службами контроля и отчетности источников TFS. Если вы не используете TFS в качестве вашей системы управления версиями, это не стоит.
@Brad Leach
Я вообще не переключался между ними, если не было убедительной функции, которая отсутствовала
Каковы веские причины использования msbuild? есть ли недостатки?
До сих пор я получаю довольно хорошее, "не беспокойтесь" от вашего ответа.
Я думаю, что они относительно сопоставимы как с функциями, так и с простотой использования. Просто от того, чтобы быть на С#, я считаю, что msbuild легче работать с чем-то nants, хотя это вряд ли является веской причиной для переключения.
Что именно вам не нужно делать? Или вы просто надеетесь, что там будет какая-то интересная функция, которую вы можете пропустить?:)
Одна супер-хорошая вещь о С# заключается в том, что если у вас есть .net-инфраструктура, у вас есть все необходимое для запуска msbuild. Это фантастика, когда вы работаете над крупными командами/проектами и имеете оборот людей/оборудования.
Лично я предпочитаю SCons над обоими из них:)
Основная причина, по которой я по-прежнему использую 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 имеет гораздо лучшую фундаментальную структуру (метаданные метаданных объектов), что значительно упрощает создание многоразовых сценариев MSBuild.
MSBuild требует времени, чтобы понять, но как только вы сделаете это очень хорошо.
Учебные материалы:
Я не вижу причин для переключения. Сам MsBuild блокирует вас в используемой структуре. Если вы используете NAnt, вы можете использовать его во многих фреймворках и вывести оболочку в msbuild, чтобы выполнить задачу построения для вас.
Я поклонник NAnt в этом отношении, потому что он немного отделяет вас от фрейма.
Я создал фреймворк, который заключает соглашения в автоматизированные сборки, и я построил его на NAnt. Он называется UppercuT, и это безумно легко использовать Build Framework.
Автоматизированная сборка проста: имя решения (1), (2) путь управления исходным кодом, (3) название компании для большинства проектов!
http://code.google.com/p/uppercut/
Несколько хороших объяснений здесь: UppercuT
MSBuild, интегрированный с Visual Studio, дает программистам меньше трений для использования системы сборки. В основном им приходится только идти "Build Solution", и все это работает, в отличие от необходимости использовать пользовательские шаги сборки и другие подобные вещи или, что еще хуже, заставить разработчиков строить, запустив внешний вид script.
Теперь я предпочитаю MSBuild больше, чем NAnt, потому что он проще. Конечно, NAnt имеет намного больше функций, более мощный и т.д., Но он может быстро выйти из-под контроля. Если у вас и ваших инженеров-строителей есть своя дисциплина, чтобы поддерживать простые сценарии NAnt, тогда все это хорошо. Тем не менее, я видел, что слишком многие системы, основанные на NAnt, выходят на юг до того уровня, когда никто не понимает, что он делает больше, и нет реального способа отладить его, помимо того, что он эквивалентен хорошему ol 'printf. В тот момент, когда вы начинаете использовать какой-либо оператор if/else или для цикла, то где IMHO начинает пахнуть.
С другой стороны, MSBuild имеет прочную основу на основе метаданных и менее подробный синтаксис. Его простота (или отсутствие функций... в зависимости от того, как вы ее видите) заставляет вас писать логику в .NET-коде с помощью новых задач вместо написания логики в разметке XML. Это поощряет повторное использование и, прежде всего, позволяет фактически отлаживать вашу систему сборки в реальном отладчике.
Единственная проблема с MSBuild - это не столь редкая ошибка (особенно в первой версии) или неясное (хотя и документированное) поведение. И если это то, что вас действительно беспокоит, привязано к Microsoft.
Я переключился с NANT на MSBuild. Проект запущен в .Net 4.0.
Мой опыт в Нанта был хорош. Вид проекта умер. И когда появился .NET 4.0, пришло время переоценить процесс сборки.
С момента выхода последней версии Nant MSBuild пошла по пути. На данный момент MSBuild - это путь. Он прост в использовании, имеет множество расширений. Я переписал свои сценарии Нанта за полтора дня. MSBuild script составляет 1/3 размера скриптов Nant.
Большая часть работы в Nant script заключалась в настройке различных сред. В MsBuild/.Net 4.0 он встроен.
Я использую MSBuild вместе с Nant, потому что текущая версия Nant еще не может компилировать приложения .NET 3.5 (это было верно, когда .NET 2.0 впервые вышел).
Единственная причина, по которой я могу видеть использование msbuild, - это использовать автоматический сервер сборки, такой как круиз-контроль. Если вы не собираетесь переключаться, я оставил бы его в покое.
Я использую Нанта, и я люблю его. Я использовал MSBuild и ненавидел его из-за этого:
Microsoft заставляет вас следовать собственной процедуре сборки, которая настолько неотъемлема по отношению к их действиям, что я, по крайней мере, не смог заставить ее работать (мне пришлось скомпилировать NET1.1, поэтому мне пришлось смешивать Nant и MSbuild), Я знаю, что вы можете создать свой собственный файл MSBuild, но я думал, что это сложно понять и поддерживать.
Элементы ItemTypes для выполнения операций с файлами слишком сложны. Вы можете заставить Nant делать то же самое и намного проще и проще (мне пришлось создать список ItemType, а затем перейти к файловым операциям).
В MsBuild вам нужно создать свою собственную DLL-задачу, в Nant вы можете это сделать, или вы можете вставить код С# в свой script, поэтому его гораздо проще продвинуть и просто построить весь проект.
Нант работает с Net1.1, MsBuild этого не делает.
Чтобы установить nant, я могу даже разархивировать и найти в моем собственном репозитории для его запуска. Установка MsBuild намного сложнее, поскольку это зависит от многих вещей из Visual Studio и т.д. (Возможно, я ошибаюсь здесь, но это кажется правдой).
Хорошо, это мое мнение...