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

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

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

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

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

4.08.2008 14:55:04
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

15
4.08.2008 22:52:31

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

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

5
4.08.2008 15:12:37

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

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

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

3
4.08.2008 15:52:42

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

1
4.08.2008 15:37:31

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

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

1
29.08.2008 04:23:19

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

0
4.09.2008 20:52:25

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

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

0
29.09.2008 14:00:55