Преимущества использования 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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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