Visual Studio 2010 всегда думает, что проект устарел, но ничего не изменилось

Question

У меня очень похожая проблема, как описано здесь .

Я также обновил смешанное решение проектов C ++ / CLI и C # с Visual Studio 2008 до Visual Studio 2010. И теперь в Visual Studio 2010 один проект C ++ / CLI всегда устаревает.

Даже если он был скомпилирован и скомпонован непосредственно перед этим, и F5 нажата, появляется сообщение «Проект устарел. Вы хотите его построить?» появляется. Это очень раздражает, потому что файл DLL очень низкоуровневый и вынуждает перестраивать практически все проекты решения.

Для моих настроек pdb установлено значение по умолчанию ( предлагает решение этой проблемы ).

Возможно ли выяснить причину, по которой Visual Studio 2010 принудительно перестраивает или считает, что проект обновлен?

Есть еще идеи, почему Visual Studio 2010 ведет себя так?

Answer 1

Я потратил много часов на то, чтобы рвать на себе волосы. Результат сборки был непоследовательным; разные проекты будут «не в курсе» по разным причинам от одной сборки до следующей последовательной сборки. В конце концов я обнаружил, что виновником был DropBox (3.0.4). Я перенаправляю исходную папку из ... \ DropBox в папку с проектами (не уверен, что в этом причина), но DropBox каким-то образом «касается» файлов во время сборки. Приостановлена ​​синхронизация, и все постоянно обновляется.

Answer 2

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

Answer 3

Большинство систем сборки используют метки времени данных, чтобы определить, когда должно произойти перестроение - метка даты / времени любых выходных файлов проверяется по времени последнего изменения зависимостей - если какая-либо из зависимостей более свежа, то цель перестраивается .

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

Answer 4

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

Неверное системное время в настройке двойной загрузки!

Оказывается, моя двойная загрузка с Ubuntu была основной причиной !! Я был слишком ленив, чтобы починить Ubuntu, чтобы перестать связываться с моими аппаратными часами. Когда я захожу в Ubuntu, время прыгает на 5 часов вперед.

Из-за неудачи я однажды построил проект с неправильным системным временем, затем исправил время. В результате все файлы сборки имели неправильные метки времени, и VS подумал бы, что все они устарели, и перестроит проект.

Answer 5

Еще одна проблема в Visual Studio 2015 с пакетом обновления 3 (SP3), но я столкнулся с похожей проблемой в Visual Studio 2013 несколько лет назад.

Моя проблема заключалась в том, что каким-то образом неправильный файл cpp использовался для предварительно скомпилированных заголовков (поэтому у меня было два файла cpp, которые создавали предварительно скомпилированные заголовки). Теперь, почему Visual Studio изменил флаги на неправильном cpp для «создания предварительно скомпилированных заголовков» без моего запроса, я понятия не имею, но это случилось ... возможно, какой-то плагин или что-то ???

В любом случае, неверный файл cpp включает файл version.h, который изменяется при каждой сборке. Таким образом, Visual Studio перестраивает все заголовки и, следовательно, весь проект.

Что ж, теперь это нормальное поведение.

Answer 6

У меня была похожая проблема с Visual Studio 2005, и мое решение состояло из пяти проектов со следующей зависимостью (сначала построенной сверху):

Video_Codec depends on nothing
Generic_Graphics depends on Video_Codec
SpecificAPI_Graphics depends on Generic_Graphics
Engine depends on Specific_Graphics
Application depends on Engine.

Я обнаружил, что проекту Video_Codec требуется полная сборка даже после полной очистки, а затем перестройки решения.

Я исправил это, убедившись, что выходной файл pdb C / C ++ и компоновщика соответствует местоположению, используемому в других рабочих проектах. Я также включил RTTI.

Answer 7

У меня был проект VC ++, который всегда компилировал все файлы и был ранее обновлен с VS2005 до VS2010 (другими людьми). Я обнаружил, что все файлы cpp в проекте, кроме StdAfx.cpp, были настроены на создание (/ Yc) предварительно скомпилированного заголовка. Я изменил это так, что только StdAfx.cpp был установлен для создания предварительно скомпилированного заголовка, а остальные были настроены на использование (/ Yu) предварительно скомпилированного заголовка, и это решило проблему для меня.

Answer 8

.NET-проекты всегда перекомпилируются независимо. Частично это позволяет поддерживать IDE в актуальном состоянии (например, IntelliSense). Я помню, как задавал этот вопрос на форуме Microsoft много лет назад, и это был ответ, который мне дали.