Зачем мне продолжать использовать Nant, когда MSBuild доступен? - PullRequest
8 голосов
/ 29 марта 2009

Я видел предыдущие вопросы и ответы. В этом одном вопросе оригинальный постер задал следующий вопрос:

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

Я не видел ответа на этот вопрос. Мне бы тоже хотелось узнать обратное. Каковы неотразимые черты Нанта?

Я думаю, для Нанта кроссплатформенность велика. Для msbuild это валюта и интеграция с Visual Studio. Это звучит правильно? Что-нибудь еще?

РЕДАКТИРОВАТЬ / Добавлено : у кого-нибудь есть сравнение списка возможностей? Кто-то сказал: «Nant имеет больше возможностей из коробки». Какие?

Имеет ли смысл объединять эти проекты, объединять усилия для взаимной выгоды? Кто-нибудь спрашивал MS, готовы ли они внести вклад в создание сообщества, например, WiX? Каковы шансы?

РЕДАКТИРОВАТЬ2 : Я только что нашел это предыдущее обсуждение , не знаю, почему я не смог найти его раньше.

Ответы [ 6 ]

14 голосов
/ 29 марта 2009

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

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

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

2 голосов
/ 29 марта 2009

Я просто считаю, что NAnt проще в использовании. Я осмелюсь сказать, что это отчасти связано с моим прошлым в Ant, но я обнаружил, что создание файла NAnt для буферов протокола было на намного проще, чем создание файла MSBuild для MiscUtil. (Даже сейчас в сборку MiscUtil есть вещи, которые я хотел бы включить, но не могу - кажется невероятно сложно сбросить вывод задачи в текстовый файл, IIRC.) Концепции проще, и, похоже, меньше ошибок при оценке коллекций файлов и т. д.

В настоящее время мне нравится использовать установку, которая раньше мне показалась действительно глупой - я использую NAnt для своего "основного" файла сборки, но вызываю MSBuild для выполнения действительного шага "скомпилировать мой проект .NET". Идея иметь две системы сборки для одного и того же проекта отвратительна, но я в основном не рассматриваю часть MSBuild как систему полной сборки - это просто простой способ компиляции, и мне никогда не нужно вручную проверять файл проекта. (Я взаимодействую с ним только через Visual Studio.) Мне удалось очень легко развить мою сборку протокольных буферов, и я сомневаюсь, что у меня был бы такой же опыт, если бы я использовал MSBuild.

Скоро я попытаюсь собрать все это с помощью Mono (когда выйдет 2.4 - до тех пор пока в gmcs есть showtoppers), и в этот момент мы увидим, насколько переносима стратегия ...

2 голосов
/ 29 марта 2009

Учитывая, что NAnt основан на Ant для Java, может быть достаточно причин, чтобы придерживаться его. Другие инструменты сборки основаны на Ant - Phing, PHP. Когда я начал использовать этот инструмент, я быстро его освоил, так как уже знал NAnt.

2 голосов
/ 29 марта 2009

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

1 голос
/ 29 марта 2009

Некоторые моменты, которые приходили на ум:

  • вы должны использовать msbuild, если вы работаете с Windows Workflow Foundation (компиляция файлов * .xoml, вероятно, это также верно для WPF)
  • если вы используете wix для сборки .msi-файла установки, вы можете использовать VisualStudio или msbuild для компиляции сценариев wix (в случае ошибки VS может перейти к проблемной строке в сценарии wix)
  • msbuild позволяет вам иметь среду сборки, максимально похожую на среду разработки / Visual Studio (например, при сборке с msbuild выполняются события postbuild, вам не нужно вручную поддерживать список файлов * .cs для задачи csc, ...)

Там, где я работаю, мы в настоящее время используем сценарии NAnt с задачей msbuild от NAntContrib.

1 голос
/ 29 марта 2009

Мы используем гибридный подход, потому что мы начали на NANT до появления MS-Build. Однако MS-Build cna может выполнять параллельные сборки для проектов, которые не зависят друг от друга, что в определенных обстоятельствах может значительно сократить время сборки. Оставляя NANT для взаимодействия с SVN, развертывания и просто компиляции MS-build, вы сокращаете время сборки примерно на 45% YMMV в зависимости от того, как вы структурируете свой sln.

...