NAnt или MSBuild, который выбрать и когда?

Ответ 1

На этой неделе я провел аналогичное расследование. Вот что я смог определить:

NAnt:

• Кросс-платформенный (поддерживает Linux/Mono). Например, может быть удобно установить веб-сайт для нескольких целей (например, Linux Apache и Windows IIS).
• 95% аналогично синтаксису Ant (легко для текущих пользователей Ant или Java-сборщиков)
• Интеграция с NUnit для запуска модульных тестов как часть сборки, а также с NDoc для документации по продуктам.

MSBuild:

• Встроенный в .NET.
• Интегрировано с Visual Studio
• Легко начать работу с MSBuild в Visual Studio - все это за кулисами. Если вы хотите глубже, вы можете отредактировать файлы.

Субъективные различия: (YMMV)

• Документация NAnt немного более проста. Например, Справочник по задаче MSBuild содержит список "Задача Csc - Описывает задачу Csc и ее параметры". (Спасибо за "помощь"?), vs Ссылка на задание NAnt "csc - компилирует С# -программы". ОБНОВЛЕНИЕ: Я заметил, что документация MSBuild была улучшена и теперь намного лучше (вероятно, наравне с NAnt).
• Нелегко понять, как отредактировать файл сборки script source (*. * proj) непосредственно из Visual Studio. С NAnt я просто имею Visual Studio рассматривать .build script как XML файл.
• По-видимому, в Visual Studio проекты веб-приложений по умолчанию не получают файл *. * proj, поэтому я с большим трудом выяснил, как даже заставить MSBuild запускаться на моем компьютере для создания развертывания script.
• NAnt не встроен в Visual Studio и должен быть добавлен либо с надстройкой, либо как "внешний инструмент". Это немного боль, чтобы настроить.
• (Edit:) Один из моих коллег поднял это - если вы хотите настроить машину сборки, используя CruiseControl для непрерывного интеграция, CruiseControl интегрируется с NAnt хорошо из коробки. ОБНОВЛЕНИЕ: CruiseControl также имеет задачу MSBuild.
• Пожалуйста, см. комментарии ниже для полного и актуального обсуждения субъективных различий.

Ответ 2

Одна из основных ничьей для MSBuild для меня (на платформах Windows) заключается в том, что она входит в состав самой .NET. Это означает, что на любой машине Windows, обновленной с помощью Центра обновления Windows, будет доступен MSBuild. Добавьте к этому тот факт, что компилятор С# также является частью самой .NET, и у вас есть платформа, которая может создавать проекты на чистых машинах. Нет необходимости устанавливать Visual Studio behemoth. NAnt, с другой стороны, должен быть явно установлен до того, как сборка может быть запущена.

Только для записи я использовал NMake, Make, Ant, Rake, NAnt и MSBuild в нетривиальных сборках в прошлом (в этом порядке). Мой любимый MSBuild, руки вниз (и я не одобряю его, потому что "это то, что использует Visual Studio" ). IMHO, это очень недооцененный инструмент построения.

Я бы сравнил NAnt против MSBuild с разницей между процедурным и функциональным программированием. NAnt довольно прост и вы-получите-что-вы-видите. MSBuild, с другой стороны, требует немного больше мысли. Кривая обучения более крутая. Но как только вы "получите", вы сможете сделать с ним удивительные вещи.

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

Ответ 3

Лично я использую оба - для одного и того же проекта.

MSBuild отлично подходит для создания решений и проектов Visual Studio - для чего он сделал.

NAnt более легко редактируется вручную, на мой взгляд, особенно если вы уже знаете Ant. NAnt может очень легко вызвать MSBuild с помощью NAntContrib. Итак, я обрабатываю NAnt script, чтобы делать такие вещи, как копирование встроенных файлов, очистка и т.д. - и вызывать MSBuild, чтобы сделать фактическую часть моего исходного кода С# в сборках.

Если вам нужен пример этого, посмотрите файл Протокол буферов протоколов. (Я бы не стал утверждать, что это невероятный NAnt script, но он выполняет эту работу.)

Ответ 4

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

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

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

• Внутри Microsoft Build Engine: использование MSBuild и Team Foundation Build
  автор Sayed Ibrahim Hashimi (январь 2009 г.)
• Развертывание .NET-приложений: обучение MSBuild и ClickOnce с помощью Sayed
  Y. Hashimi (сентябрь 2008 г.)

Ответ 5

KISS= Использовать MSBuild.

Зачем добавлять что-то еще в микс, если у вас есть что-то, что сделает разумную работу из коробки? Когда MSBuild прибыл, NAnt умер. И Mono будет иметь реализацию MSBuild, (xbuild).

DRY= Использовать MSBuild.

Спросите себя, что вы хотите от системы сборки? Я хочу создать систему сборки, которая также используется моей IDE вместо сохранения двух разных конфигураций.

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

Ответ 6

Одна вещь, которую я заметил, упоминал несколько плакатов: нужно вручную отредактировать файлы .csproj(или .vbproj и т.д.).

MSBuild позволяет настраивать эти. * proj файлы с использованием файлов .user. Если у меня есть проект с именем MyCreativelyNamedProject.csproj и вы хотите настроить задачи MSBuild внутри него, я могу создать файл с именем MyCreativelyNamedProject.csproj.user и использовать CustomBeforeMicrosoftCommonTargets и CustomAfterMicrosoftCommonTargets для настройки этих файлов.

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

Итак, использование NAnt или MSBuild действительно сводится к пониманию:

• Если вы уже знакомы с Ant, используйте NAnt. Кривая обучения будет очень простой.
• Если вы не знакомы ни с одним из инструментов, MSBuild уже интегрирован с Visual Studio и не требует дополнительных инструментов.

Также стоит добавить, что MSBuild в значительной степени гарантированно работает со всеми новыми версиями .NET и Visual Studio, как только они освобождаются, тогда как NAnt может иметь некоторое отставание.

Ответ 7

Я использую оба в том, что сценарии NAnt вызывают MSBuild. Моя главная причина оставаться с NAnt - изолировать. Позвольте мне объяснить, почему я считаю, что это важно:

• Добавление зависимостей к вашему проекту. Файл сборки NAnt чуждо Visual Studio (в моем случае я рассматриваю это как профессионал), поэтому Visual Studio не пытается ничего с ним делать. Задачи MSBuild встроены в часть решения и могут ссылаться на другие задачи MSBuild. Я получил исходный код от кого-то еще, чтобы узнать, что я не смог создать, потому что задачи сообщества MSBuild не были установлены. То, что я нахожу особенно разочаровывающим, - это то, что Visual Studio просто не построило и не выбросило кучу ошибок, из-за чего я потерял время отладки. Это, несмотря на то, что запрошенная сборка могла быть продолжена (например, для сборки отладки) без каких-либо дополнительных задач MSBuild. Короче: мне не нравится добавлять зависимости к моему проекту, если я могу его избежать.

• Я не доверяю Visual Studio, насколько я могу бросить свою команду разработчиков. Это восходит к ранним дням Visual Studio, когда он будет убивать мой HTML. Я до сих пор не пользуюсь дизайнером (например, на конференции недавно я обнаружил, что коллеги сделали то же самое). Я обнаружил, что Visual Studio может испортить зависимости и номера версий в DLL файле (я не могу реплицировать это, но это происходило в проекте последовательно и вызвало много горя и потерянного времени). Я прибегал к процедуре сборки, которая использует Visual Studio для построения только в режиме отладки. Для производства я использую NAnt, чтобы я контролировал все внешне. Visual Studio просто не может вмешиваться, если я создаю с помощью NAnt.

PS: Я веб-разработчик и не занимаюсь разработкой Windows Forms.

Ответ 8

Пока я не очень хорошо знаком с MsBuild, у меня создается впечатление, что некоторые ключевые отличия с обеих сторон могут быть дополнены дополнениями:

• MsBuildTasks
• NantContrib

Недавно мне пришлось создать проект Silverlight в Нанта. Я обнаружил, что жизнь будет проще, если я просто сделаю это с MsBuild - я закончил вызов задачи MsBuild из Nant script, поэтому я полагаю, что это не слишком необычно, чтобы смешивать и сопоставлять два.

Помимо этого, я полагаю, это будет вопрос личных предпочтений - очевидно, что вы можете управлять некоторыми/большинством функций MsBuild из Visual Studio, если это ваша вещь. Нант кажется более гибким и более подходящим, если вы предпочитаете писать сценарии вручную, и если вы выйдете из мира Java, вы, вероятно, будете рядом с ним.

Ответ 9

В итоге я использовал оба. При перепроектировании нашей системы сборки я столкнулся с непростой задачей. А именно, я не мог избавиться от .vcproj(и семьи), потому что мы все использовали VS для обновления файлов проекта, настроек и конфигураций. Таким образом, без огромного процесса дублирования и ошибок, мы не могли бы основывать нашу систему сборки на новом наборе файлов.

По этой причине я решил сохранить "proj" файлы VS и использовать MSBuild (это файлы MSBuild, по крайней мере VS2005 и VS2008 используют файлы проекта MSBuild). Для всего остального (пользовательская конфигурация, модульное тестирование, упаковка, подготовка документации...) Я использовал NAnt.

Для непрерывного интегрирования я использовал CruiseControl. Таким образом, у нас были скрипты CC, которые запускали задания NAnt, которые для создания используемого MSBuild.

Последнее замечание: MSBuild НЕ поддерживает проекты установки! Таким образом, вы застряли с вызовом DevEnv.com или напрямую с помощью Visual Studio. Это то, что я закончил делать, но я отключил проект установки по умолчанию из всех конфигураций решений, поскольку разработчикам обычно не нужно было их создавать, и если они это сделают, они могут вручную выбрать их для сборки.

Ответ 10

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

Вы также можете проверить Задачи сообщества MSBuild, которые похожи на NAntContrib.

Ответ 11

Документация и учебные пособия, доступные для NAnt, упрощают начало изучения скриптов сборки с помощью NAnt. Как только я получил ведение NAnt и создаю скрипты сборки, я начал переводить это знание в MSBuild (я сделал X в NAnt, как мне сделать X в MSBuild?). Документация Microsoft обычно предполагает довольно высокий уровень знаний, прежде чем она будет полезна.

Причиной переключения с NAnt на MSBuild является то, что MSBuild является более актуальным. К сожалению, последний выпуск NAnt был 8 декабря 2007 года, а MSBuild 4.0 (.NET 4.0) не за горами. Похоже, что проект NAnt умер.

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

Ответ 12

YDeliver от Manoj - это структура построения, построенная поверх PSake. Он имеет богатый набор библиотечных функций, возможность определять рабочие процессы, и мы использовали его для доставки более шести корпоративных проектов в производство.

Используйте его в сочетании с TeamCity, CruiseControl или что-нибудь, что может работать PowerShell.

Ответ 13

Мы используем оба. NAnt отвечает за все "скриптовые" вещи, такие как копирование, развертывание на IIS, создание пакетов и MSBuild отвечает за построение решения. Затем мы можем избежать проблем с не поддерживаемым .NET 4.0 с помощью новой версии NAnt.

NAnt также более масштабируема. Если мы хотим перенести сценарии развертывания на производственные серверы, мы копируем только файл сборки и устанавливаем правильную версию .NET - без проблем с Visual Studio с файлами csproj:)

Ответ 14

Мы используем FlubuCore (переписываем Flubu). Это библиотека С# с открытым исходным кодом для создания проектов и выполнения сценариев развертывания с использованием кода С#.

Основные преимущества flubu, которые я вижу:

• Поддержка .Net Core (работает с linux и macOS)
• Легко учиться, потому что вы полностью пишете build script на С#.
• Довольно много встроенных задач (компиляция, запуск тестов, управление iis, создание пакета развертывания, публикация пакетов nuget...)
• Ссылка на любую библиотеку .net в buildscript
• Вы можете написать свои собственные задачи или легко запустить внешние программы в script.

Вы можете найти flubu на nuget:

Искать FlubuCore.Runner, если это необходимо для проекта .net

Поиск dotnet-flubu для if u it it for core core project

Простой пример использования flubu:

  protected override void ConfigureBuildProperties(IBuildPropertiesContext context)
{
    context.Properties.Set(BuildProps.NUnitConsolePath,
        @"packages\NUnit.ConsoleRunner.3.6.0\tools\nunit3-console.exe");
    context.Properties.Set(BuildProps.ProductId, "FlubuExample");
    context.Properties.Set(BuildProps.ProductName, "FlubuExample");
    context.Properties.Set(BuildProps.SolutionFileName, "FlubuExample.sln");
    context.Properties.Set(BuildProps.BuildConfiguration, "Release");
}

protected override void ConfigureTargets(ITaskContext session)
{
    var loadSolution = session.CreateTarget("load.solution")
        .SetAsHidden()
        .AddTask(x => x.LoadSolutionTask());

    var updateVersion = session.CreateTarget("update.version")
        .DependsOn(loadSolution)
        .SetAsHidden()
        .Do(TargetFetchBuildVersion);      

    session.CreateTarget("generate.commonassinfo")
       .SetDescription("Generates common assembly info")
        .DependsOn(updateVersion)
       .TaskExtensions().GenerateCommonAssemblyInfo()        

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");

    var unitTest = session.CreateTarget("unit.tests")
        .SetDescription("Runs unit tests")
        .DependsOn(loadSolution)
        .AddTask(x => x.NUnitTaskForNunitV3("FlubuExample.Tests"));

     session.CreateTarget("abc").AddTask(x => x.RunProgramTask(@"packages\LibZ.Tool\1.2.0\tools\libz.exe"));    

    session.CreateTarget("Rebuild")
        .SetDescription("Rebuilds the solution.")
        .SetAsDefault()
        .DependsOn(compile, unitTest);
}

//// Some custom code
public static void TargetFetchBuildVersion(ITaskContext context)
{
    var version = context.Tasks().FetchBuildVersionFromFileTask().Execute(context);

    int svnRevisionNumber = 0; //in real scenario you would fetch revision number from subversion.
    int buildNumber = 0; // in real scenario you would fetch build version from build server.
    version = new Version(version.Major, version.Minor, buildNumber, svnRevisionNumber);
    context.Properties.Set(BuildProps.BuildVersion, version);
}

}

Здесь вы можете найти полные примеры: https://bitbucket.org/zoroz/flubu.core.examples

Wiki можно найти здесь: https://github.com/flubu-core/flubu.core/wiki

Ответ 15

Мы используем FlubuCore. Это библиотека С# с открытым исходным кодом для создания проектов и выполнения сценариев развертывания с использованием кода С#.

Простой пример использования flubu:

protected override void ConfigureTargets(ITaskContext session)
{           

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");
}

Более подробную информацию о flubu вы можете найти здесь: select-for-build-tool-msbuild -nant-or-something-else