Как уже сказали Марникс и Антон, VS обычно так и делает. Но если в вашем решении много проектов, которые зависят друг от друга, и вы вносите изменения в компонент, который будет использоваться всеми или большинством других проектов, он должен будет также собрать другие, чтобы убедиться, что все работает как положено .
Обновление
Так что, если он начинает перекомпилироваться, даже если вы не внесли никаких изменений, нам нужно выяснить, как VS пытается выяснить, что ему нужно делать в инкрементальной сборке.
Для этого он просто проверяет дату и время каждого файла и наличие каких-либо изменений. Если да, перекомпилируйте этот файл и все его зависимые элементы (например, изменения в stdafx.h приведут к полной перестройке, поскольку обычно каждый исходный файл ссылается на этот).
Но есть и исключения из этого поведения. Например, проект установки всегда будет перестраиваться, даже если не было внесено никаких изменений (из-за этого я обычно исключаю проект установки из процесса сборки и запускаю его только вручную, когда это необходимо).
Так что, если у вас есть только проекты C / C ++, C #, VB и т. Д., Которые обычно поддерживают инкрементные сборки, должно быть что-то, что меняется между двумя сборками, даже если вы ничего не меняете.
Вот несколько возможностей:
- Команда до или после сборки, которая вносит изменения в исходный файл
- это может быть автоматическое обновление при добавлении номера ревизии из вашего репозитория в ресурс файла AssemblyInfo.
- или команда copy / delete, которая вносит некоторые изменения в вашу структуру каталогов (я использовал это один раз, чтобы удалить выходной каталог в команде перед сборкой, чтобы принудительно перестроить каждую сборку).
- Автоинкремент версии сборки
- возможно, используя
[assembly: AssemblyVersion("1.0.*")]
или какой-либо другой внешний процесс для увеличения номера сборки
Если один из вышеперечисленных шагов происходит с модулем, от которого зависят все или большинство других ваших проектов, то все должно быть перестроено.