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

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

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

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

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

Ответ 1

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

Есть некоторые фундаментальные различия между этими двумя, возможно, лучше всего выделяется этот разговор между некоторыми поклонниками NAnt и Microsoftie.

Интересно, что Джереми Миллер задал совершенно противоположный вопрос в своем блоге в прошлом году.

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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