Visual studio проект устарел
Обновлено: 07.07.2024
У меня очень похожая проблема, как описано здесь.
Настройки моего pdb установлены на значение по умолчанию (предлагаемое решение этой проблемы).
Возможно ли получить причину, по которой Visual Studio 2010 заставляет перестроить или думает, что проект обновлен?
Любые другие идеи, почему Visual Studio 2010 ведет себя так:
Только для Visual Studio/Express 2010. См. Другие (более простые) ответы для VS2012, VS2013 и т.д.
Чтобы найти отсутствующие файлы, используйте информацию из статьи Включить систему проектов С++ протоколирование, чтобы включить ведение журнала отладки в Visual Studio и позволить ему просто рассказать вам, что вызывает восстановление:
-
Откройте файл devenv.exe.config (находится в %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ или в %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ ). Для экспресс-версий конфигурационный файл имеет имя V*Express.exe.config .
Добавьте следующее после строки </configSections> :
Найдите журнал отладки для любых строк формы:
devenv.exe Информация: 0: Project 'Bla\Bla\Dummy.vcxproj' не обновляется, потому что отсутствует сбор данных 'Bla\Bla\SomeFile.h'.
(Я просто нажал Ctrl + F и искал not up to date ). Это будут ссылки, которые заставляют проект постоянно "устареть".
Примечание. Если вы используете 2012 или позже, то фрагмент должен быть:
В Visual Studio 2012 я смог добиться того же результата легче, чем в принятом решении.
Я изменил эту опцию в меню Инструменты → Параметры → Проекты и решения → Сборка и запуск → * Объяснение вывода сборки проекта MSBuild "от минимального до диагностического".
Затем в выводе сборки я нашел те же строки, выполнив поиск "не обновляется":
Проект "blabla" не обновляется. Элемент проекта "c:\foo\bar.xml" имеет атрибут "Копировать в выходной каталог", установленный в "Копировать всегда".
Это случилось со мной сегодня. Я смог отслеживать причину: проект включал заголовочный файл, который больше не существовал на диске.
Удаление файла из проекта решило проблему.
Мы также столкнулись с этой проблемой и выяснили, как ее решить.
Проблема была такой, как указано выше: "Файл больше не существует на диске".
Это не совсем правильно. Файл существует на диске, но файл .VCPROJ ссылается на файл где-то еще.
Вы можете "открыть" это, перейдя в "include file view" и щелкнув по каждому включенному файлу по очереди, пока не найдете тот, который Visual Studio не может найти. Затем вы добавите этот файл (как существующий элемент) и удалите ссылку, которая не может быть найдена, и все в порядке.
Допустимым является вопрос: как Visual Studio может даже построить, если он не знает, где находятся файлы include?
Мы полагаем, что файл .vcproj имеет некоторый относительный путь к файлу-нарушителю где-то, что он не отображается в графическом интерфейсе Visual Studio, и это объясняет, почему проект действительно будет построен, даже если древовидное представление включений неверно.
Принятый ответ помог мне на правильном пути выяснить, как решить эту проблему для запутанного проекта, с которым мне пришлось начать работать. Тем не менее, мне пришлось иметь дело с очень большим количеством плохих включенных заголовков. С помощью подробного вывода отладки, удаление одного из них заставило IDE замерзнуть в течение 30 секунд при выводе отладки, что заставило процесс идти очень медленно.
Я удалил cpp и некоторые файлы заголовков из решения (и с диска), но все еще имел проблему.
Thing - каждый файл, который использует компилятор, находится в файле *.tlog в вашем каталоге temp. Когда вы удаляете файл, этот *.tlog файл не обновляется. Чтобы файл, используемый инкрементными строками, проверял, обновлен ли ваш проект.
Либо отредактируйте этот .tlog файл вручную, либо очистите проект и перестройте его.
У меня была аналогичная проблема, но в моем случае отсутствовали файлы, была ошибка в том, как был определен выходной файл pdb: я забыл суффикс .pdb(я обнаружил трюк регистрации отладки).
Чтобы решить проблему, я изменил в файле vxproj следующую строку:
Еще одно простое решение, на которое ссылается Visual Studio Forum.
Изменение конфигурации: меню Инструменты → Параметры → Проекты и решения → Настройки проекта VС++ → Режим обозревателя решений для отображения всех файлов.
Затем вы можете увидеть все файлы в обозревателе решений.
Найдите файлы, отмеченные желтым значком, и удалите их из проекта.
Я не знаю, имеет ли кто-то еще эту проблему, но у моих свойств проекта "Configuration Properties" -> C/C++ -> "Debug Information Format" установлено значение "Нет", и когда я переключил его обратно на "База данных программы (/Zi) по умолчанию", это остановилось проект от перекомпиляции каждый раз.
Visual Studio 2013 - "Принудительная перекомпиляция всех исходных файлов из-за отсутствия PDB". Я включил подробный вывод сборки, чтобы найти проблему: я включил "Подробный" вывод сборки в разделе "Инструменты" → "Проекты и решения" → "Сборка и запуск".
У меня было несколько проектов, все С++, я установил параметр для параметров проекта: (C/С++ → Отладочный информационный формат) в базу данных программы (/Zi) для проблемного проекта. Однако это не остановило проблему для этого проекта. Проблема возникла из одного из других проектов С++ в решении.
Я установил все проекты на С++ в "Program Database (/Zi)". Это устранило проблему.
Опять же, проект, сообщающий о проблеме, не был проблемным проектом. Попробуйте настроить все проекты на "Program Database (/Zi)", чтобы устранить проблему.
Сегодня я встретил эту проблему, но это было немного иначе. У меня был проект CUDA DLL в моем решении. Компиляция в чистом решении была в порядке, но в противном случае она не удалась, и компилятор всегда рассматривал проект CUDA DLL как не обновленный.
Но в моем решении отсутствует файл заголовка. Тогда я выяснил причину в моем случае.
Я раньше менял проект Intermediate Directory, хотя это не вызывало проблем. И теперь, когда я изменил проект промежуточного каталога проекта CUDA DLL обратно на $(Конфигурация) \, все снова работает правильно.
Я предполагаю, что существует небольшая проблема между настройкой CUDA Build Customization и промежуточным каталогом промежуточного уровня.
У меня была схожая проблема, и я выполнил приведенные выше инструкции (принятый ответ), чтобы найти недостающие файлы, но не почесывая голову. Вот мое резюме того, что я сделал. Чтобы быть точным, они не пропускают файлы, поскольку они не требуются для сборки проекта (по крайней мере, в моем случае), но они являются ссылками на файлы, которые не существуют на диске, которые действительно не требуются.
Вот моя история:
Под Windows 7 файл находится в %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\% . Есть два похожих файла devenv.exe.config.config и devenv.exe.config . Вы хотите изменить позже один.
В Windows 7 у вас нет разрешения на редактирование этого файла в файлах программы. Просто скопируйте его в другое место (рабочий стол), изменив его, а затем скопируйте обратно в расположение файлов программ.
У меня было много файлов, которые были ненужными ссылками, и их устранение устраняло проблему, описанную выше.
Второй способ сразу найти все недостающие файлы
Существует второй способ найти эти файлы сразу, но он включает (a) источник управления и (б) интеграцию его с Visual Studio 2010. Используя Visual Studio 2010, добавьте проект в нужное место или фиктивное местоположение в исходном элементе управления. Он попытается добавить все файлы, в том числе те, которые еще не существуют на диске, но указаны в файле проекта. Перейдите в свое программное обеспечение для управления версиями, например Perforce, и оно должно пометить эти файлы, которые не существуют на диске в другой цветовой схеме. Perforce показывает их с черным замком на них. Это ваши недостающие ссылки. Теперь у вас есть список всех них, и вы можете удалить их из своего файла проекта с помощью "Блокнота", и ваш проект не будет жаловаться на устаревание.
чтобы обновить проект, созданный в более ранней версии Visual Studio, просто откройте проект в последней версии Visual Studio. Visual Studio предлагает обновить проект до текущей схемы.
Если вы выберете " нет", проект не будет обновлен. для проектов, созданных в Visual Studio 2010 и более поздних версий, можно по-прежнему использовать проект в более новой версии Visual Studio. Просто задайте свойства проекта, чтобы они продолжали работать с более старым набором инструментов. если вы оставляете старую версию Visual Studio на компьютере, его набор инструментов доступен в более поздних версиях. например, если проект должен продолжать работать в Windows XP, можно выполнить обновление до Visual Studio 2019. Затем вы указываете набор инструментов в качестве v141_xp или более ранней версии в свойствах проекта. Дополнительные сведения см. в разделе Использование собственного многоплатформенного нацеливания в Visual Studio для сборки старых проектов.
Если выбрать Да, проект будет обновлен на месте. Его нельзя преобразовать обратно в предыдущую версию. В сценариях обновления рекомендуется создать резервную копию существующих файлов проекта и решения.
Обновление отчетов
При обновлении проекта появляется отчет об обновлении. Отчет также сохраняется в папке проекта как UpgradeLog.htm. В отчете об обновлении отображается сводка проблем, обнаруженных во время преобразования. В нем перечислены некоторые сведения о внесенных изменениях, включая:
Код, который больше не компилируется четко из-за улучшения соответствия компилятора или изменений в стандарте.
код, основанный на Visual Studio или Windowsных функциях, которые больше не доступны. или файлы заголовков, которые не включаются в установку по умолчанию Visual Studio или были удалены из продукта.
Код, который больше не компилируется из-за изменений в API, таких как переименованные API, измененные сигнатуры функций или устаревшие функции.
Код, который больше не компилируется из-за изменений в диагностике, например предупреждения об ошибке
Ошибки компоновщика из-за измененных библиотек, особенно при использовании параметра/NODEFAULTLIB.
Ошибки времени выполнения или непредвиденные результаты из-за изменений в поведении.
Ошибки, появившиеся в средствах. если у вас возникла ошибка, сообщите о ней команде Visual C++ по стандартным каналам поддержки или с помощью страницы Community Visual Studio разработчика C++ .
Некоторые обновленные проекты и решения могут быть успешно собраны без изменений. Однако большинству проектов, скорее всего, потребуется внести изменения в параметры проекта и исходный код. Не существует единого правильного способа устранения этих проблем, но мы рекомендуем использовать поэтапный подход. Прежде чем начать, ознакомьтесь с обзором возможных проблем с обновлением , чтобы получить дополнительные сведения о многих типичных ошибках.
задайте предпочтительные версии набора инструментов платформы, стандарта языка C++ и Windows SDK версии (если применимо). (Project > Свойства > Свойства конфигурации > Общие)
При наличии большого количества ошибок можно временно отключить некоторые параметры, пока вы их исправите. чтобы отключить этот /permissive- параметр, используйте Project > свойства > конфигурации свойства > языка C/C++ > . чтобы отключить параметр анализа кода , используйте свойства конфигурации Project > свойства > > Code Analysis.
Убедитесь, что все зависимости существуют и что пути к включаемым файлам или папкам библиотеки указаны правильно. (Project > Свойства > Свойства конфигурации > VC++ каталоги)
Выявление и устранение ошибок, вызванных ссылками на интерфейсы API, которые больше не существуют.
Устраните все оставшиеся ошибки, препятствующие компиляции. Сведения об устранении распространенных ошибок см. в статье Обзор возможных проблем с обновлением .
Снова включите /permissive- и исправьте все новые ошибки, вызванные несоответствием коду, который ранее был скомпилирован в MSVC.
Включите анализ кода, чтобы выявление потенциальных проблем или устаревших шаблонов кода, которые больше не считаются приемлемыми. Если анализ кода помечает много ошибок, можно отключить некоторые предупреждения, чтобы сосредоточиться на наиболее важных. Интегрированная среда разработки может помочь быстро устранить проблемы некоторых типов.
Рассмотрим другие возможности для модернизации кода. Например, замените пользовательские структуры данных и алгоритмы на шаблоны из стандартной библиотеки C++ или в библиотеку с открытым исходным кодом. Используя стандартные функции, можно упростить поддержку кода другими пользователями. Можно быть уверенным, что этот код тщательно проверен и проверен многими экспертами по стандартам и широкому сообществу C++.
У меня очень похожая проблема, как описано здесь.
даже если он был скомпилирован и связан непосредственно до и Ф5 попал, messagebox " проект устарел. Хотите его построить?" кажется. Это очень раздражает, потому что DLL файл очень низкоуровневый и заставляет практически все проекты решения перестраиваться.
Мои настройки pdb установлены на значение по умолчанию (предлагаемое решение этой проблемы).
возможно ли получить причину, по которой Visual Studio 2010 заставляет перестроить или считает, что проект обновлен?
любые другие идеи, почему Visual Studio 2010 ведет себя так?
только для Visual Studio / Express 2010. См. другие (более простые) ответы для VS2012, VS2013 и т. д.
найти недостающий файл(ы) используйте информацию из статьи включить ведение журнала системы проектов C++ включить ведение журнала отладки в Visual Studio и пусть это просто сказать вам что вызывает перестройку:
-
открыть (находится в %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ или %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ ). Для экспресс-версий файл конфигурации имени V*Express.exe.config .
добавить следующее после </configSections> строку:
поиск в журнале отладки для любых строк формы:
команду devenv.exe информация: 0: проект ' Bla\Bla\Dummy.vcxproj ' не актуален, потому что ввод сборки 'Бла\Бла\Некий-Файл.ч' отсутствует.
(Я просто нажал Ctrl+F и искал not up to date ) это будут ссылки, заставляющие проект постоянно быть "устаревшим".
Примечание: при использовании 2012 или более поздней версии фрагмент должен быть:
в Visual Studio 2012 я смог достичь того же результата проще, чем в принятом решении.
Я изменил опцию в меню инструменты → опции → проекты и решения → построить и запустить → * MSBuild проект сборки вывода многословие " от минимальный до Диагностика.
затем в выходных данных сборки я нашел те же строки, выполнив поиск "не в курсе":
проект "blabla" не актуален. C:\foo\bar пункт проекта.xml имеет атрибут "копировать в выходной каталог", установленный в "копировать всегда".
Это случилось со мной сегодня. Я смог отследить причину: проект включал файл заголовка, который больше не существовал на диске.
удаление файла из проекта решило проблему.
мы также столкнулись с этой проблемой и выяснили, как ее решить.
проблема была, как указано выше " файл больше не существует на диске."
Это не совсем верно. Файл существует на диске, но .Файл VCPROJ ссылается на файл где-то еще.
вы можете "обнаружить" это, перейдя в "Включить представление файла" и нажав на каждый включить файл по очереди, пока не найдете тот, который Visual Studio не может найти. Затем вы добавляете этот файл (как существующий элемент) и удалить ссылку, которая не может быть найдена, и все в порядке.
допустимый вопрос: как Visual Studio может даже создавать, если она не знает, где находятся включенные файлы?
мы думаем .файл vcproj имеет некоторый относительный путь к файлу-нарушителю, который он не показывает в графическом интерфейсе Visual Studio, и это объясняет, почему проект будет фактически построен, даже если древовидное представление includes неверно.
принятый ответ помог мне на правильном пути, чтобы выяснить, как решить эту проблему для испорченного проекта, с которым я должен был начать работать. Однако мне пришлось иметь дело с очень большим количеством плохих заголовков include. С подробным выводом отладки удаление одного из них привело к замораживанию IDE в течение 30 секунд при выводе отладочной извержения, что сделало процесс очень медленным.
Я удалил cpp и некоторые заголовочные файлы из решения (и с диска), но все еще имел проблему.
дело в том, что каждый файл, используемый компилятором, идет в *.файл tlog в каталоге temp. Когда вы удаляете файл, это *.файл tlog не обновляется. Этот файл используется инкрементными сборками для проверки актуальности проекта.
изменить это .tlog файл вручную или очистить проект и перестроить.
у меня была аналогичная проблема, но в моем случае отсутствовали файлы, была ошибка в определении выходного файла pdb: я забыл суффикс .pdb (я узнал с трюком ведения журнала отладки).
чтобы решить проблему, я изменил в файле vxproj следующую строку:
у меня была эта проблема в VS2013 (обновление 5), и для этого может быть две причины, обе из которых вы можете найти, включив "подробный" вывод сборки в разделе "Инструменты"->"проекты и решения"->"сборка и запуск".
Я не знаю, есть ли у кого-то еще такая же проблема, но свойства моего проекта имели "Configuration Properties" -> C/C++ -> "Debug Information Format" установите значение "нет", и когда я переключил его обратно на" базу данных программы по умолчанию (/Zi)", это остановило проект от перекомпиляции каждый раз.
еще одно простое решение, на которое ссылается Форум Visual Studio.
изменение конфигурации: menu инструменты → опции → проекты и решения → настройки проекта VC++ → Режим Обозревателя Решений to показать все файлы.
затем вы можете увидеть все файлы в обозревателе решений.
найти файлы, отмеченные желтым значком и удалять их из проект.
Я встретил эту проблему сегодня, однако это было немного по-другому. У меня был проект CUDA DLL в моем решении. Компиляция в чистом решении была в порядке, но в противном случае она не удалась, и компилятор всегда рассматривал проект DLL CUDA как не обновленный.
Я попробовал решение от этот пост.
но в моем решении нет отсутствующего файла заголовка. Затем я выяснил причину в моем случае.
Я изменил промежуточный каталог проекта раньше, хотя неприятностей это не доставило. и теперь, когда я изменил промежуточный каталог проекта CUDA DLL на $(Configuration)\, все снова работает правильно.
Я думаю, что есть небольшая проблема между настройкой сборки CUDA и не стандартным промежуточным каталогом.
у меня была аналогичная проблема и я следовал приведенным выше инструкциям (принятый ответ), чтобы найти отсутствующие файлы, но не без почесывания головы. Вот мое резюме того, что я сделал. Чтобы быть точным, это не отсутствующие файлы, так как они не требуются проекту для сборки (по крайней мере, в моем случае), но они являются ссылками на файлы, которые не существуют на диске, которые на самом деле не требуются.
вот моя история:
под Windows 7 файл находится по адресу %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\% . Есть два похожих файла devenv.exe.config.config и devenv.exe.config . Ты хочешь переодеться позже.
в Windows 7 у вас нет разрешения на редактирование этого файла в program files. Просто скопируйте его где-нибудь еще (рабочий стол), измените его и скопируйте обратно в папку program files.
у меня было много файлов, ненужных ссылок и удаление их всех исправили проблему, описанных выше.
Второй способ найти все отсутствующие файлы сразу
существует второй способ найти эти файлы сразу, но он включает в себя (a) управление версиями и (b) интеграцию с Visual Studio 2010. Использование Visual Studio 2010, добавьте свой проект в нужное место или фиктивное место в системе управления версиями. Он попытается добавить все файлы, в том числе те, которые не существуют на диске, а также ссылки в файле проекта. Перейти к программному обеспечению управления версиями, как необходимости, и он должен отметить эти файлы, которые не существуют на диске в другой цветовой схеме. Волей-неволей показывает их с Черным замком. Эти недостающие ссылки. Теперь у вас есть список все они, и вы можете удалить их все из своего файла проекта с помощью блокнота, и ваш проект не будет жаловаться на то, что от дата.
Visual Studio 2013 -- "принудительная перекомпиляция всех исходных файлов из-за отсутствия PDB". Я включил подробный вывод сборки, чтобы найти проблему: я включил" подробный "вывод сборки в разделе "Инструменты" → "проекты и решения" → "сборка и запуск".
У меня было несколько проектов, все C++, я установил опцию для параметров проекта: (C / C++ → формат отладочной информации) в базу данных программы (/Zi) для проблемного проекта. Однако это не остановило проблему для этого проекта. Проблема пришла из одного из других проектов C++ в решении.
Я все проекты C++ в "Program Database (/Zi)". Это исправило проблему.
опять же, проект, сообщающий о проблеме, не был проблемным проектом. Попробуйте установить все проекты в " Program Database (/Zi)", чтобы устранить проблему.
для меня это было наличие несуществующего файла заголовка в "файлах заголовков" внутри проекта. После удаления этой записи (щелкните правой кнопкой мыши > исключить из проекта) первый раз перекомпилируется, а затем напрямую
========== сборка: 0 успешно, 0 не удалось, 5 обновлено, 0 пропущено ==========
и не было предпринято никаких попыток восстановления без изменений. Я думаю, что это проверка перед сборкой, реализованная VS2010 (не уверен, что документально, может быть), которая запускает "AlwaysCreate" флаг.
Если вы используете команду MSBuild командной строки (не Visual Studio IDE), например, если вы нацеливаете AppVeyor или просто предпочитаете командную строку, вы можете добавить этот параметр в командную строку MSBuild:
как документально здесь (предупреждение: обычная многословность MSDN). Когда сборка завершится, найдите строку will be compiled в файле журнала, созданном во время сборки, MyLog.log .
Я использую Visual Studio 2013 Professional с обновлением 4, но не нашел разрешения ни с одним из других предложений, однако мне удалось решить проблему для моего командного проекта.
вот что я сделал, чтобы вызвать проблему -
- создан новый объект класса (Project -> Add Class)
- переименовал файл через Обозреватель решений и нажал да, когда меня спросили, хочу ли я автоматически переименовать все ссылки на матч
вот что я сделал, чтобы решить проблему -
- перейдите в Team Explorer Home
- Нажмите Проводник Управления Версиями
- перейдите в папку, в которой находятся все файлы класса/проекта
- нашел исходное имя файла в списке и удалил его с помощью правой кнопки мыши
- построить
Если это так для вас, просто убедитесь, что вы удаляете фантомный файл, а не фактический тот, который вы хотите сохранить в проекте.
у меня была эта проблема и я нашел это:
устранение:
в моем случае один из проектов содержит несколько файлов IDL. Компилятор MIDL создает файл данных DLL с именем " dlldata.c ' для каждого из них, независимо от имени файла IDL. Это заставило Visual Studio компилировать файлы IDL в каждой сборке, даже без изменений в любом из файлов IDL.
обходным путем является настройка уникального выходного файла для каждого файла IDL (компилятор MIDL всегда генерирует такой файл, даже если параметр / dlldata опущено):
- щелкните правой кнопкой мыши файл IDL
- выберите свойства-MIDL-выход
- введите уникальное имя файла DllData Файл свойства
Я потратил много часов на то, чтобы рвать на себе волосы. Результат сборки не был согласованным; разные проекты будут "не актуальными" по разным причинам от одной сборки до следующей последовательной сборки. В конце концов я обнаружил, что виновником был в Dropbox (3.0.4). Я соединяю исходную папку . \DropBox в папку " Мои проекты "(не уверен, что это причина), но DropBox как-то" касается " файлов во время сборка. Приостановлена синхронизация и все постоянно вверх-к-дата.
существует довольно много потенциальных причин, и, как уже отмечалось, вам нужно сначала диагностировать их, установив MSBuild многословие в "Diagnostic". В большинстве случаев указанная причина будет объяснительной, и вы сможете действовать на нее немедленно, но иногда MSBuild ошибочно утверждает, что некоторые файлы изменены и должны быть скопированы.
Если это так, вам нужно либо отключить туннелирование NTFS, либо дублировать выходную папку в новое место. здесь это больше словами.
для меня проблема возникла в проекте WPF, где у некоторых файлов было свойство "Build Action" установлено в "Resource", а их "Copy to Output Directory" установлено в "Copy if newer". Решение, казалось, состояло в том, чтобы изменить свойство "копировать в выходной каталог" на "не копировать".
msbuild знает, что нельзя копировать файлы "ресурсов" в выходные данные, но все равно запускает сборку, если их нет. Может, это можно считать ошибкой?
Это очень полезно, с ответами здесь намекая, как заставить msbuild пролить бобы на то, почему он продолжает строить все!
Это случилось со мной несколько раз, а затем ушло, прежде чем я смог понять, почему. В моем случае это было:
неправильное системное время в настройке двойной загрузки!
из-за невезения я построил проект один раз, с неправильным системным временем, а затем поправил время. В результате все файлы сборки имели неправильные метки времени, и VS подумал бы, что все они устарели, и перестроил бы проект.
большинство систем сборки используют метки времени данных, чтобы определить, когда должны произойти перестройки - отметка даты/времени любых выходных файлов проверяется на последнее измененное время зависимостей-если какая-либо из зависимостей более свежая, то цель перестраивается.
Это может вызвать проблемы, если какая-либо из зависимостей каким-либо образом получает недопустимую метку времени данных, поскольку трудно, чтобы метка времени любого вывода сборки когда-либо превышала метку времени файла, предположительно созданного в будущее :Р
у меня была аналогичная проблема с Visual Studio 2005, и мое решение состояло из пяти проектов в следующей зависимости (сначала построенной сверху):
я обнаружил, что проект Video_Codec хотел полную сборку даже после полной очистки, а затем перестроить решение.
я исправил это путем обеспечения pdb выходной файл как C / C++, так и компоновщика соответствовал местоположению, используемому другими рабочими проектами. Я также включил RTTI.
еще один на Visual Studio 2015 SP3, но я столкнулся с аналогичной проблемой в Visual Studio 2013 несколько лет назад.
моя проблема заключалась в том, что для предварительно скомпилированных заголовков использовался неправильный файл cpp (поэтому у меня было два файла cpp, которые создали предварительно скомпилированные заголовки). Теперь, почему Visual Studio изменила флаги на неправильном cpp для "создания предварительно скомпилированных заголовков" без моего запроса, я понятия не имею, но это произошло. может, какой-нибудь плагин.
в любом случае, неправильный файл cpp включает в себя версию.H файл, который изменяется при каждой сборке. Таким образом, Visual Studio перестраивает все заголовки и из-за этого весь проект.
Ну, теперь он вернулся к нормальному поведению.
Я перенес решение с VS2008 на VS2010 (SP1).
Теперь один из моих проектов никогда не находит покоя в том, чтобы быть актуальным. Каждая сборка имеет следующий результат:
У меня была аналогичная проблема, когда один из включаемых файлов, перечисленных в проекте, на самом деле не существовал. Я удалил файл, но забыл удалить его из проекта.
Затем средство проверки зависимостей считает, что проект устарел, но построитель не находит ничего для построения.
Решение - подождать до этого времени, и проблема волшебным образом исчезнет. У меня была такая же проблема, мой файл TZRES.DLL - 17.07.2018 19:54, время 17.07.2018 15:15
Для сборок командной строки msbuild.exe вы можете использовать / многословие: подробный и искать вывод для
- "будет скомпилирован как" найти компиляции
- «Требуется компиляция исходного кода» для поиска ссылок
Примечание. Вывод можно передать по конвейеру в файл с помощью msbuild.exe / verbosity: detail> output.txt
В прошлом мне удавалось использовать DebugView в VS2010 для поиска файлов для удаления, но сегодня этот подход не работал. Я не смог найти ЛЮБУЮ ссылку на отсутствующие файлы заголовков, найденные с помощью DebugView, в любом из моих XML-файлов кода или проектов. Я также извлек устаревшие файлы из TFS, чтобы попробовать как они присутствуют, так и отсутствуют на моем компьютере.
Затем я использовал GREP для поиска во всем каталоге решений, и единственные результаты были в двоичных файлах: файлы старого кода * .obj, файлы проекта * .pdb и vc100.idb. Я не знаю, как эти файлы изменяются / заменяются во время сборки и восстановления, поэтому я не уверен, что предыдущая ссылка в одном из этих файлов была ответственна за утверждение, что старые файлы заголовков отсутствовали.
Надеюсь, это поможет кому-то в будущем, и спасибо за приведенную выше информацию, с которой я начал!
В Visual Studio 2010 я устранил ложные перестройки решения для многих проектов, оставив многопроцессорную компиляцию (/ MP) не установленной (жаль!). Раньше у меня он был включен. Найдите флаг здесь: Общие свойства> C / C ++> Общие> Многопроцессорная компиляция. Кроме того, я заметил, что смог устранить ложные перестройки отдельных проектов, перестраивая каждый проект индивидуально; затем сборка каждого показала, что все они актуальны.
У меня такая же проблема.
Основная причина: неправильная версия сборки VS (32-битная и 64-битная)
Решение: переключите режим отладки / выпуска с 32-битного на 64-битный или наоборот.
Я переместил решение в новую папку, и каждый раз, когда я создавал новую версию или пытался отладить, он хотел утверждать, что все проекты, составляющие решение, устарели, даже если он только что их построил.
Я просмотрел все файлы .vcxproj, использовал DebugView с CPS = 4 (см. Ответ @Bzzt выше) и обнаружил, что он ищет файлы заголовков в их СТАРОМ месте. Поскольку решение было перемещено, а не скопировано, этих файлов не было.
Что в конечном итоге решило для меня, так это очистка раствора и выполнение одной перестройки. После этого «AlwaysCreate» больше не заставлял «строить» все подпроекты. Вы должны очищать каждую конфигурацию (отладку и выпуск) отдельно, но как только она будет восстановлена из чистого состояния, все будет хорошо.
В моем случае он на самом деле не строил, но MSBuild или что-то еще решило, что что-то устарело, использовало некоторый кешированный путь к файлу, которого больше не существовало. Очистка и восстановление заменили этот кеш, а затем он построил, как ожидалось
Вы должны также проверить другие файлы, кроме .h. В моем проекте Readme.txt отсутствовал.
Согласно этой теме на MSDN:
В моем случае в VS10 это было связано с отсутствием (но несоответствием файлов .h, поэтому нет дополнительной ошибки для выявления) в папках проекта.
Быстрая проверка того, что все файлы проекта могут открываться в редакторе, решила эту проблему.
У меня было два проекта, содержащих один и тот же файл. Когда второй проект был построен, он снова скомпилировал файл, изменив дату и время касания. Это, в свою очередь, установило флаг AlwaysCreate для первого проекта.
Читайте также: