MSBuild ускорение: как удалить ненужные сборки проекта?

Question

У меня есть решение с несколькими проектами. Допустим,

проект A зависит от проектов B и C

проект B зависит от проекта C

Когда я запускаю свое решение на локальной машине, VS строит каждый проект один раз, и это занимает 1 минуту. Однако на нашей сборочной машине сборка занимает около 4 минут, и, как я понимаю из журналов MSBuild, она выглядит следующим образом:

сборка A -> сборка B для A, сборка C для A

сборка B -> сборка C для B

То есть он строит несколько проектов несколько раз ... Как я могу ускорить процесс сборки?

P.S. Это не вопрос дополнительных 3 минут, мне просто интересно, почему он так сильно отличается от моей локальной сборки машины?

Answer 1

Я не уверен в вашем порядке сборки. Иногда TeamBuild может выглядеть так, как будто он строит проекты снова и снова, но он строит для разных конфигураций. Посмотрите и убедитесь, что вы не определили несколько FlavorsToBuild.

Кроме того, если вы не хотите каждый раз заново проверять и перестраивать, вы можете указать это в нижней части вашего файла TFSBuild.

<PropertyGroup>
    <IncrementalBuild>true</IncrementalBuild>
</PropertyGroup>-->

Поместите это прямо перед тегом </Project>.

Answer 2

Этот образец, кажется, работает для меня. TestLib.Extra зависит от TestLib. Если я изменю что-то в TestLib, оба проекта будут построены. Если я изменю только в TestLib.Extra, будет построен только один, и если я вообще ничего не изменю, они просто сообщат Пропуск целевого "CoreCompile", потому что все выходные файлы обновлены и т. д.

<Target Name="Build">
  <MSBuild Targets="Build" Projects="TestLib\TestLib.csproj" />
  <MSBuild Targets="Build" Projects="TestLib.Extra\TestLib.Extra.csproj" />
</Target>

Хитрость заключается в том, чтобы использовать цель "Build" проектов, а не "Rebuild". Разница между ними по существу такая же, как разница между командами «Построить» и «Восстановить» в меню сборки в Visual Studio.

Редактировать

Это также хорошо работает, если проекты включены в файл решения, и вместо этого вы указываете решение для построения:

<Target Name="Build">
  <MSBuild Targets="Build" Projects="TestLib.sln" />
</Target>

Answer 3

Я делаю это следующим образом. Это несколько сложная система сборки, но основная идея такова.

1. Библиотеки, которые используются во многих решениях, создаются в известной папке. Это достигается тем, что я использую файл проекта msbuild, который собирает эти общие библиотеки.
2. При создании других файлов csproj в решении мы копируем файлы csproj, а затем используем манипуляции xslt для замены ссылок проекта ссылками на dll для этих общих библиотек.
3. Затем сценарии сборки собирают эти измененные файлы csproj с использованием пользовательских файлов проекта msbuild, которые мы поддерживаем в соответствии с каждым решением. Мы не создаем файлы .sln. Эти пользовательские файлы проекта представляют собой группу элементов файлов .csproj в правильном порядке зависимостей.

Может быть, это поможет вам достичь того, чего вы хотите.

Answer 4

Вы используете ключ / maxcpucount? Может быть разница в количестве процессоров между вашей локальной машиной и машиной сборки. Этот параметр также может отличаться между файлом msbuild и настройкой visual studio, что также объясняет разницу, которую вы видите во время сборки.

Answer 5

Возможно, как и у нас, ваш сервер сборки является виртуальной машиной (по крайней мере, в 10 раз медленнее).

Кроме того, TFS (и, возможно, другие) выполняет новую проверку сборки, поэтому ему придется собирать все проекты независимо.