Visual Studio 2015 — событие перед сборкой, чтобы определить, какие проекты компилировать

Question

Visual Studio 2015 — событие перед сборкой, чтобы определить, какие проекты компилировать

PreBuild отключить компиляцию избыточных проектов для ускорения цикла компиляции.

У меня есть VS15 ALL решение, которое содержит много проектов.

У меня есть один проект, PreBuild, что все остальные проекты зависят, значит, это PreBuild компилируется первым.
Кроме того, у нас также есть PostBuild проект, который сделает еще больше работы, как только бинарники будут готовы.

Все проекты настроены на встраивание Release режим (что желательно).
Когда член команды хочет выпустить несколько бинарных файлов, он нажимает F7, Build Solution,
Теперь PreBuild, активирует отдельный выделенный процесс, который вычисляет, какие проекты должны быть выпущены. Характер расчета не имеет отношения к этому обсуждению.

Из множества проектов часто бывает необходимо выпустить только несколько проектов. Однако, как только PreBuild процесс завершен, ВСЕ проекты будут скомпилированы, что занимает очень много времени.

Можно ли после начала сборки решения изменить выпущенные проекты?

Разработчик выбирает только соответствующие проекты и только создает их.
PreBuild Убийство & Возродить. Как только желаемые проекты рассчитаны, PreBuild убивает процесс VS15 и активирует cmd, компилируя только соответствующие проекты.

Изменить файл ALL.sln и удалить ненужные проекты.
Это сработало бы, если бы я изменил этот файл до начала процесса, но я не уверен, что он сработает, если это изменение произойдет во время процесса.

0

c++compilation pre-build-event visual-studio

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Я думаю о простейшем способе, сохраняя при этом большую часть текущей инфраструктуры: иметь выделенный проект, который вызывает сборку релиза (вычисляя зависимости и вызывая msbuild) и настраивая VS, чтобы можно было выбрать только этот проект для сборки , Все изнутри вашего ALL.sln, поэтому остальные функции остаются. шаги:

Избавьтесь от проектов PreBuild / PostBuild. Я предполагаю, что PostBuild, который вы упоминаете, также предназначен для фактических сборок релиза; если не просто оставить его там. Обратите внимание: не требуется, чтобы все проекты зависели от проекта PreBuild, вы уже избавились от одного бремени обслуживания.

Добавьте один единственный проект, который будет делать сборку релиза, скажем ReleaseBuild, Такое имя также лучше, чем проекты PreBuild / PostBuild, поскольку в нем четко указано намерение проекта. Подходит проект Makefile, хотя технически он может быть таким же простым, как файл msbuild с одной целью Build. Сконфигурируйте командную строку сборки так, чтобы она делала все, что нужно, то есть выясняла, что собирать, а затем собирать. Для примера: скажем, вы используете Powershell для этого, вы должны настроить командную строку сборки, чтобы

Powershell -NoProfile -File BuildRelease.ps1 $(Platform)

и BuildRelease.ps1 содержит что-то вроде

$projectsToRelease = CalculateMyProjectsForRelease()
$platform = $Args[0]
$projectsToRelease | %{& msbuild $_ "/p:Configuration=Release;Platform=$platform"}

В Configuration Manager добавьте дополнительную конфигурацию под названием Deploy или так. Это будет использоваться для выбора того, что собирать: у вас, вероятно, уже есть конфигурации Debug и Release. Они остаются на месте и просто используются, чтобы построить все. Идея в том, что эта дополнительная конфигурация позаботится о создании реальной версии. Это вполне соответствует стандартному способу работы в VS, и его легко обнаружить и понять новичкам. Используя флажки, сделайте так, чтобы, когда выбрана конфигурация Deploy, была собрана только ReleaseBuild, и ни одна из других, тогда как при выборе Debug или Release проект ReleaseBuild не создается. Выглядит так:

Чтобы создать релиз, выберите Deploy в раскрывающемся меню конфигурации на панели инструментов VS и нажмите F7 (или любым другим способом, который вы используете для вызова Build Solution). Любые ошибки / предупреждения сборки будут проанализированы и показаны как обычно в списке ошибок.

Это также легко расширить: предположим, что у вас есть только несколько версий сборки выпуска, просто добавьте больше конфигураций, таких как DeployA DeployB DeployC, и настройте для них командную строку сборки.

1