MSBuild, интегрируемый с Visual Studio, дает программистам меньше трения при использовании системы сборки. В основном это сводится к тому, что им нужно только перейти к «Build Solution», и все это работает, в отличие от необходимости использовать Custom Build Steps и другие подобные вещи, или, что еще хуже, вынуждают разработчиков строить путем запуска какого-то внешнего скрипта.
Теперь я в основном предпочитаю MSBuild, а не NAnt, потому что это проще. Конечно, у NAnt гораздо больше возможностей, он более мощный и т. Д., Но он может быстро выйти из-под контроля. Если у вас и у ваших инженеров по сборке есть дисциплина, чтобы сохранять простые сценарии NAnt, то это все хорошо. Тем не менее, я видел слишком много систем, основанных на NAnt, идущих на юг, к точке, где никто больше не понимает, что они делают, и нет никакого реального способа отладки этого, кроме как сделать эквивалент хорошего старого printf. В тот момент, когда вы начинаете использовать какой-то оператор if / else или цикл, именно здесь, IMHO, он начинает пахнуть.
С другой стороны, MSBuild имеет прочную основу, основанную на метаданных, и менее подробный синтаксис. Его простота (или отсутствие функций ... в зависимости от того, как вы это видите) заставляет вас писать логику в коде .NET с помощью новых задач, а не писать логику в разметке XML. Это поощряет повторное использование и, прежде всего, позволяет вам фактически отладить вашу систему сборки в реальном отладчике.
Единственная проблема с MSBuild - нерегулярная ошибка (особенно в первой версии) или неясное (хотя задокументированное) поведение. И, если это действительно беспокоит вас, будучи привязанным к Microsoft.