Преимущества использования MSBuild или NAnt по сравнению с запуском DevEnv.exe из командной строки

Question

Может кто-нибудь объяснить, какие преимущества дает использование такого инструмента, как MSBuild (или NAnt), для создания коллекции проектов по сравнению с запуском DevEnv.exe из командной строки?

Коллега, с которым я работал в прошлом, объяснил, что (по крайней мере, с более старыми версиями Visual Studio) использование DevEnv.exe было намного медленнее, чем другие методы, но я не читал никаких доказательств того, сейчас спорный вопрос, что начиная с 2005 года Visual Studio использует MSBuild под капотом.

Я знаю, что одно преимущество использования MSBuild позволяет создавать ваши проекты, не требуя установки Visual Studio на сборочные машины, но я не был уверен, были ли другие.

Answer 1

Одна из причин в том, что создание продукта намного больше, чем просто его компиляция. Такие задачи, как создание установок, обновление номеров версий, создание условных выпусков, распространение окончательных пакетов и т. Д., Могут быть намного проще благодаря тому, что предоставляют эти инструменты (и их расширения).

Хотя вы могли бы делать все это с помощью обычных скриптов, использование NAnt или MSBuild дает вам прочную основу для всего этого. Обе программы поддерживают многие сообщества, включая дополнительные задачи, которые можно загрузить (например, проект Задачи сообщества MSBuild ). Кроме того, есть поддержка для них во многих сторонних продуктах и ​​продуктах с открытым исходным кодом.

Если вы просто заинтересованы в компиляции (а не во всем процессе сборки), вы можете найти единственное преимущество MSBuild в поддержке для сборки с несколькими процессорами .

Answer 2

Очевидный ответ моей команды заключается в том, что никто не установил Visual Studio , в частности, мы не устанавливаем Visual Studio на наши серверы сборки / CI.

Answer 3

Что касается C #, devenv.exe 2005 запускает встроенный компилятор, что может привести к нехватке памяти для значительных решений. Msbuild прибегает к запуску процесса csc.exe для каждого проекта. Проекты, которые не компилируются с помощью devenv / build, прекрасно работают с msbuild. Надеюсь, вам понравится эта причина.

Answer 4

Основная причина использования внешнего инструмента сборки, такого как NAnt или MsBuild, заключается в способности автоматизировать процесс сборки и, таким образом, обеспечивать постоянную обратную связь о состоянии вашей системы. Кроме того, они могут использоваться для множества вещей, помимо «чистой» сборки, и именно здесь вы действительно начинаете получать от них ценность, это чрезвычайно ценно иметь возможность создавать и тестировать ваше приложение с помощью одной команды.

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

Answer 5

У нас есть большая система, состоящая из C #, управляемого C ++ и простых старых неуправляемых сборок / dll C ++. Существует код C ++, который зависит от управляемого кода C ++, который зависит от кода C #, который зависит от управляемого кода C ++, который зависит от простого старого кода C ++ (вот так!). Когда мы настраивали нашу среду автоматической сборки несколько лет назад, мы обнаружили, что MSBuild.exe неправильно обрабатывает все имеющиеся у нас зависимости.

Работая с Microsoft, мы смогли решить некоторые проблемы, но не все. Если мне не изменяет память, мы никогда не сможем собрать сборки C #, которые зависят от управляемых библиотек C ++. Таким образом, мы закончили создание собственного сценария сборки, который вызывал devenv.exe из командной строки, и он работал просто отлично.

Конечно, это было с VS2005, сейчас это можно исправить, но скрипт все еще работает, поэтому мы еще не рассмотрели проблему.

Answer 6

Мы экспериментируем с переходом с DevEnv на инструмент (Visual Build Pro), который использует MsBuild под капотом, и мы получили ошибку «Ссылка на сборку System.Drawing ...» для проекта, который не нуждается это и что прекрасно в Visual Studio.