Я знаю, что есть другие NAnt и MSBuild связанные вопросы о Stack Overflow, но я не мог найти прямого сравнения между ними и вот здесь вопрос.
Когда следует выбирать NAnt над MSBuild? Какой из них лучше для чего? Является ли NAnt более подходящим для проектов на дому/с открытым исходным кодом и MSBuild для рабочих проектов? Каков опыт работы с любым из двух?
На этой неделе я провел аналогичное расследование. Вот что я смог определить:
NAnt:
MSBuild:
Субъективные различия: (YMMV)
Одна из основных ничьей для 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, если вы также тяготеете к программированию функционального или логического стиля - если вы готовы потратить немного времени и усилий, прежде чем ощутить ощутимые результаты (конечно, я также твердо верю, что инвестиции в конечном итоге платят и вы можете делать более мощные вещи более эффективно).
Лично я использую оба - для одного и того же проекта.
MSBuild отлично подходит для создания решений и проектов Visual Studio - для чего он сделал.
NAnt более легко редактируется вручную, на мой взгляд, особенно если вы уже знаете Ant. NAnt может очень легко вызвать MSBuild с помощью NAntContrib. Итак, я обрабатываю NAnt script, чтобы делать такие вещи, как копирование встроенных файлов, очистка и т.д. - и вызывать MSBuild, чтобы сделать фактическую часть моего исходного кода С# в сборках.
Если вам нужен пример этого, посмотрите файл Протокол буферов протоколов. (Я бы не стал утверждать, что это невероятный NAnt script, но он выполняет эту работу.)
NAnt имеет больше функций из коробки, но MSBuild имеет гораздо лучшую фундаментальную структуру (метаданные метаданных объекта), что значительно упрощает создание многоразовых сценариев MSBuild.
MSBuild требует времени, чтобы понять, но как только вы сделаете это очень хорошо.
Учебные материалы:
KISS= Использовать MSBuild.
Зачем добавлять что-то еще в микс, если у вас есть что-то, что сделает разумную работу из коробки? Когда MSBuild прибыл, NAnt умер. И Mono будет иметь реализацию MSBuild, (xbuild).
DRY= Использовать MSBuild.
Спросите себя, что вы хотите от системы сборки? Я хочу создать систему сборки, которая также используется моей IDE вместо сохранения двух разных конфигураций.
Лично мне хотелось бы услышать какие-то реальные аргументы в пользу NAnt, потому что я просто не могу думать о том, что действительно держит воду.
Одна вещь, которую я заметил, упоминал несколько плакатов: нужно вручную отредактировать файлы .csproj(или .vbproj и т.д.).
MSBuild позволяет настраивать эти. * proj файлы с использованием файлов .user. Если у меня есть проект с именем MyCreativelyNamedProject.csproj и вы хотите настроить задачи MSBuild внутри него, я могу создать файл с именем MyCreativelyNamedProject.csproj.user и использовать CustomBeforeMicrosoftCommonTargets и CustomAfterMicrosoftCommonTargets для настройки этих файлов.
Кроме того, как NAnt, так и MSBuild могут быть настроены на содержание сердца через пользовательские задачи MSBuild и через расширения NantContrib.
Итак, использование NAnt или MSBuild действительно сводится к пониманию:
Также стоит добавить, что MSBuild в значительной степени гарантированно работает со всеми новыми версиями .NET и Visual Studio, как только они освобождаются, тогда как NAnt может иметь некоторое отставание.
Я использую оба в том, что сценарии 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.
Пока я не очень хорошо знаком с MsBuild, у меня создается впечатление, что некоторые ключевые отличия с обеих сторон могут быть дополнены дополнениями:
Недавно мне пришлось создать проект Silverlight в Нанта. Я обнаружил, что жизнь будет проще, если я просто сделаю это с MsBuild - я закончил вызов задачи MsBuild из Nant script, поэтому я полагаю, что это не слишком необычно, чтобы смешивать и сопоставлять два.
Помимо этого, я полагаю, это будет вопрос личных предпочтений - очевидно, что вы можете управлять некоторыми/большинством функций MsBuild из Visual Studio, если это ваша вещь. Нант кажется более гибким и более подходящим, если вы предпочитаете писать сценарии вручную, и если вы выйдете из мира Java, вы, вероятно, будете рядом с ним.
В итоге я использовал оба. При перепроектировании нашей системы сборки я столкнулся с непростой задачей. А именно, я не мог избавиться от .vcproj(и семьи), потому что мы все использовали VS для обновления файлов проекта, настроек и конфигураций. Таким образом, без огромного процесса дублирования и ошибок, мы не могли бы основывать нашу систему сборки на новом наборе файлов.
По этой причине я решил сохранить "proj" файлы VS и использовать MSBuild (это файлы MSBuild, по крайней мере VS2005 и VS2008 используют файлы проекта MSBuild). Для всего остального (пользовательская конфигурация, модульное тестирование, упаковка, подготовка документации...) Я использовал NAnt.
Для непрерывного интегрирования я использовал CruiseControl. Таким образом, у нас были скрипты CC, которые запускали задания NAnt, которые для создания используемого MSBuild.
Последнее замечание: MSBuild НЕ поддерживает проекты установки! Таким образом, вы застряли с вызовом DevEnv.com или напрямую с помощью Visual Studio. Это то, что я закончил делать, но я отключил проект установки по умолчанию из всех конфигураций решений, поскольку разработчикам обычно не нужно было их создавать, и если они это сделают, они могут вручную выбрать их для сборки.
Недавно я переключился с NAnt на MSBuild из-за его способности создавать VS-решения. Я все же иногда использую NAnt.
Вы также можете проверить Задачи сообщества MSBuild, которые похожи на NAntContrib.
Документация и учебные пособия, доступные для 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, но теперь они отстают.
YDeliver от Manoj - это структура построения, построенная поверх PSake. Он имеет богатый набор библиотечных функций, возможность определять рабочие процессы, и мы использовали его для доставки более шести корпоративных проектов в производство.
Используйте его в сочетании с TeamCity, CruiseControl или что-нибудь, что может работать PowerShell.
Мы используем оба. NAnt отвечает за все "скриптовые" вещи, такие как копирование, развертывание на IIS, создание пакетов и MSBuild отвечает за построение решения. Затем мы можем избежать проблем с не поддерживаемым .NET 4.0 с помощью новой версии NAnt.
NAnt также более масштабируема. Если мы хотим перенести сценарии развертывания на производственные серверы, мы копируем только файл сборки и устанавливаем правильную версию .NET - без проблем с Visual Studio с файлами csproj:)
Мы используем FlubuCore (переписываем Flubu). Это библиотека С# с открытым исходным кодом для создания проектов и выполнения сценариев развертывания с использованием кода С#.
Основные преимущества flubu, которые я вижу:
Вы можете найти 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
Мы используем 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