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

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

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

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

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

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

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

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

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

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

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

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

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

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

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