Избегайте сборки дважды при использовании общего проекта вместе со сгенерированным кодом сборки

Question

У меня есть визуальное решение для студии с несколькими проектами. Каждый генерирует файлы кода как часть предварительной сборки (классы grp c через Grp c .Tools). Существует также общий проект, который расширяет частичные классы, созданные как часть этой предварительной сборки.

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

Что я могу сделать в этом сценарии? Можно ли как-то переместить валидацию / компиляцию общего проекта «дальше вниз» по конвейеру компиляции? Или даже просто настроить этот конкретный проект, чтобы попытаться скомпилировать дважды, если есть ошибка? Или это та вещь, с которой мне реально нужно просто жить, учитывая то, что я делаю - я не нашел никаких других ссылок на эту проблему. Это не , что большая проблема, и это случалось бы не очень часто, но я бы хотел разумно с ней справиться, если смогу.

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

Если мне неясно, это общий проект, как в .shproj, проект, который не компилируется отдельно. Проект, который ссылается на него, включает его и строит все вместе как один.

Answer 1

Если проект B зависит от проекта A, то проект A должен быть собран до проекта B. Visual Studio достаточно умен, чтобы определить порядок сборки таким образом. Кстати, это также одна из причин (среди многих), почему циклические зависимости просто не могут работать.

Я подозреваю, что ваши проекты в настоящее время не связаны через зависимость, поскольку эта проблема не возникла бы, если бы были такие ссылка. Возможно, ваш второй проект обращается к файлам первого проекта через файловую систему? Это всего лишь предположение.

Вы можете использовать это «A перед B», которое зависит от поведения A процесса сборки, в ваших интересах. Пусть проект B (т. Е. Проект, который вам нужен go второй) добавит проект A (то есть проект, который вам нужен go первый) в качестве зависимости. Это вынуждает VS строить их в соответствующем порядке.

---

Некоторые замечания:

• Я не уверен, что VS способен пропускать зависимости, которые вы добавляете, но которые на самом деле не зависят от (т.е. вы никогда не ссылаетесь на его содержание). Я не могу найти никакого подтверждения в этом вопросе (но отсутствие доказательств не является доказательством отсутствия!) Но даже если это так, это можно легко обойти, если иметь фиктивный класс в B, который фактически ссылается и использует что-то из проект A.
• Имейте в виду, что во время обычной сборки VS не перестраивает проекты, которые не изменились с момента последней сборки. Если это проблема для вас (не уверен, что вы не добавили достаточно контекста), обязательно всегда перестраивайте или очищайте, чтобы убедиться, что будет запущена новая сборка.

Answer 2

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

То, что это только иногда и может быть исправлено «повторной попыткой» очков в одном - вы получили условие гонки . Но состояние гонки во время компиляции - это не то, о чем я раньше слышал или сталкивался.

Я получил несколько возможных культовых сценариев. Но, в конце концов, условия гонки, как известно, трудно отладить: - Может быть, компилятор, который имеет дело с общим проектом, возвращается до его завершения - что должно быть невозможно - или - Может быть, что-то заставляет основные проекты компилироваться до того, как файлы общих проектов становятся готов. - Может быть, сторонний инструмент - например, сканер вирусов или автоматическое создание резервных копий? - Может быть, скомпилированные файлы общих проектов размещаются на сетевом диске, и иногда между «скомпилированными» и «видимыми для всех других компьютеров в сети» задерживается лишь небольшая задержка?

Обычно правильные способы для зависимых Сборник должен иметь дело с такими вопросами. Это означает, что то, что у вас есть, вероятно, не самая стабильная установка.