nAnt все еще поддерживается и подходит для .net 3.5/VS2008?

Question

Я использую MSBuild для сборки своих вещей. Я хочу использовать CruiseControl.net как Build Server.

Теперь CCNET ссылается на nAnt много, но похоже, что ccnet может выполнять большую часть информации, которую nant может выполнять через конфигурацию проекта и msbuild. Кроме того, nAnt кажется немного неподдерживаемым, с бета-релизом, который почти год назад.

Вкратце: я действительно доволен MSBuild (тем более, что это официальный «компилятор») и немного неудобно с nAnt, но я не хочу преждевременно судить.

Каковы были бы причины использования nAnt над MSBuild? Особенно с ccnet, который, похоже, немного перекрывает возможности с точки зрения возможностей (и добавляет связанные с автоматическим сбором вещи)

Answer 1

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

Есть некоторые фундаментальные различия между ними, возможно, лучше всего выделены this conversation between some NAnt fans and a Microsoftie.

Интересно, что Jeremy Miller задал совершенно противоположный вопрос on his blog в прошлом году.

Answer 2

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

Я не могу ответить на вопрос «все еще поддерживаемый», но я бы сказал, если вам уже удобно с nAnt, тогда это, вероятно, жизнеспособно. Если вы (или кто-то из вашей группы) знаком с MSBuild, то это прекрасный способ пойти так же хорошо.

Answer 3

Честно говоря, это зависит от того, что лучше подходит для вашей среды. Если вы используете множество инструментов, отличных от Microsoft, nunit, ccnet, ncover. Вы, вероятно, найдете лучшую поддержку с nant. Альтернативно, если вы используете MSTest, TFSBuild, вы, вероятно, найдете MSBuild лучшей средой. Я бы изучил и то, и другое, каждое из которых будет более плавным в вашей среде.

Answer 4

Если у вас уже есть куча пользовательских задач, которые вы используете с nAnt, придерживайтесь его - вы мало выигрываете с MSBuild. Тем не менее, похоже, что ничего не может сделать nAnt, что MSBuild не может в своей основе. Оба могут вызывать внешние инструменты, оба могут запускать пользовательские задачи на основе .NET, и у них есть множество задач сообщества.

Мы используем MSBuild здесь по той же причине, что и вы, это стандартная система сборки для VS, и у нас не было никаких специфичных для nAnt вещей.

MSBuildCommunityTasks - отличная сторонняя база задач для начала и охватывает большинство пользовательских материалов, которые я когда-либо делал в nAnt, включая поддержку VSS и Subversion.

Answer 5

CC.NET - это просто технология сервера сборки, а не технология сценариев сборки. Мы используем CC.NET на работе, чтобы очень успешно вызывать скрипты сборки MSBuild без проблем.

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

Answer 6

Как и многие люди, которые уже указали, ответ здесь «это зависит». Есть такие вещи, как повторяющиеся операции, которые намного проще и чище в NAnt. См. the MSDN forums для обсуждения этого вопроса.

Answer 7

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

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