Перестроение решения завершается ошибкой в ​​30 % случаев

У нас есть более 100 проектов в решении, и некоторые из проектов включают другие проекты в качестве ссылок на проекты. Чистая сборка/восстановление заняли слишком много времени, поэтому я поискал и нашел довольно хорошее решение для оптимизации времени сборки/восстановления:

  1. Установка одного и того же пути вывода для Debug/Release во всех проектах с разницей в $(Configuration).
  2. Установка ссылки на проект для Copy Local на false, потому что проект, на который ссылаются, должен быть там.

После многократного тестирования я обнаружил, что перестроение VS Solution терпит неудачу в 30% случаев из-за metadata * could not be found. Я знаю, что означает ошибка, но я не знаю, как это происходит.

Есть ли у кого-нибудь идеи, как улучшить успех Solution's Rebuild?


c++ rebuild c# projects-and-solutions multiple-projects
person ursyka    schedule 30.01.2018    source источник
comment
вау, 100 проектов, должно быть время обеда, прежде чем vs2017 даже откроется   -  person TheGeneral    schedule 30.01.2018
comment
VS может не перестроить библиотеки DLL сборки, если они заблокированы. Это может привести к ошибке «Не удалось найти метаданные». Однако эта ошибка слишком общая (VS строит многопоточные проекты, и не было доступных библиотек DLL проекта). Я считаю, что в журнале должно быть более конкретное сообщение об ошибке. Есть ли у вас какие-либо другие ошибки в окне вывода?   -  person oleksa    schedule 30.01.2018
comment
Похоже, что некоторые проекты могут создавать выходные файлы с одинаковыми именами, которые мешают друг другу.   -  person user7860670    schedule 30.01.2018
comment
Вы пытались отключить многопоточную компиляцию?   -  person Mateusz    schedule 30.01.2018
comment
@saruman: у него есть свои плюсы :)   -  person ursyka    schedule 31.01.2018
comment
@oleksa: Были точно такие же, но несколько ошибок для разных файлов * .dll.   -  person ursyka    schedule 31.01.2018
comment
@m.rogalski: я изменил максимальное количество параллельных сборок проекта с 4 на 2, и ошибка не возникает. Но на восстановление требуется больше времени.   -  person ursyka    schedule 31.01.2018
comment
@ursyka Это обычная проблема при работе с мультизависимыми проектами. Скорее всего, когда вы нажимаете сборку, проект пытается собрать 4 проекта из последней ветви дерева зависимостей, но проблема начинает появляться, когда одна сборка одного проекта выполняется быстрее, чем другая (например, в 99% случаев).   -  person Mateusz    schedule 31.01.2018

Ответы (1)


arrow_upward
2
arrow_downward

Частая проблема с неудачными перестроениями иногда возникает (как было отмечено в комментариях) параллельных сборок, когда между проектами существуют зависимости (т. е. одна цель сборки требует, чтобы сначала были собраны другие проекты, поскольку она потребляет выходные данные проектов.)

Можно установить зависимости сборки в VS - версия VS не указана, но вы должны иметь возможность щелкнуть правой кнопкой мыши проект и выбрать «Зависимости сборки», что затем дает вам два варианта: зависимости сборки и порядок сборки.

Используя эти параметры, вы можете определить, какие проекты зависят от других (т. е. запретить VS пытаться создавать проекты там, где те, от которых он зависит, еще не были построены) и, если вам нужно, указать определенный порядок сборки проектов. .

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

См.: Как создать и удалить зависимости проекта

person Rags    schedule 30.01.2018
comment
Разве это не так, что VS сам делает заказ на сборку? - person ursyka; 31.01.2018
comment
VS знает о порядке сборки проекта из ссылок на проекты, мне никогда не приходилось устанавливать зависимости сборки вручную - person oleksa; 31.01.2018
comment
Да, порядок сборки должен быть автоматическим, но вы можете изменить его, если он запутается. Что иногда и происходит. - person Rags; 31.01.2018