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

Ответ 1

Только для 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>:

  <system.diagnostics>
    <switches>
      <add name="CPS" value="4" />
    </switches>
  </system.diagnostics>
  

• Перезапустить Visual Studio
• Откройте DbgView и убедитесь, что он захватывает отладочный вывод
• Попробуйте отладить (нажмите F5 в Visual Studio)

• Найдите журнал отладки для любых строк формы:

  devenv.exe Информация: 0: Project 'Bla\Bla\Dummy.vcxproj' не обновляется, потому что отсутствует сбор данных 'Bla\Bla\SomeFile.h'.

  (Я просто нажал Ctrl + F и искал not up to date). Это будут ссылки, которые заставляют проект постоянно "устареть".

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

Примечание. Если вы используете 2012 или позже, то фрагмент должен быть:

<system.diagnostics>
  <switches>
   <add name="CPS" value="Verbose" />
  </switches>
</system.diagnostics>

Ответ 2

В Visual Studio 2012 я смог добиться того же результата легче, чем в принятом решении.

Я изменил эту опцию в меню Инструменты → Параметры → Проекты и решения → Сборка и запуск → * Объяснение вывода сборки проекта MSBuild "от минимального до диагностического".

Затем в выводе сборки я нашел те же строки, выполнив поиск "не обновляется":

Проект "blabla" не обновляется. Элемент проекта "c:\foo\bar.xml" имеет атрибут "Копировать в выходной каталог", установленный в "Копировать всегда".

Ответ 3

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

Удаление файла из проекта решило проблему.

Ответ 4

Мы также столкнулись с этой проблемой и выяснили, как ее решить.

Проблема была такой, как указано выше: "Файл больше не существует на диске".

Это не совсем правильно. Файл существует на диске, но файл .VCPROJ ссылается на файл где-то еще.

Вы можете "открыть" это, перейдя в "include file view" и щелкнув по каждому включенному файлу по очереди, пока не найдете тот, который Visual Studio не может найти. Затем вы добавите этот файл (как существующий элемент) и удалите ссылку, которая не может быть найдена, и все в порядке.

Допустимым является вопрос: как Visual Studio может даже построить, если он не знает, где находятся файлы include?

Мы полагаем, что файл .vcproj имеет некоторый относительный путь к файлу-нарушителю где-то, что он не отображается в графическом интерфейсе Visual Studio, и это объясняет, почему проект действительно будет построен, даже если древовидное представление включений неверно.

Ответ 5

Принятый ответ помог мне на правильном пути выяснить, как решить эту проблему для запутанного проекта, с которым мне пришлось начать работать. Тем не менее, мне пришлось иметь дело с очень большим количеством плохих включенных заголовков. С помощью подробного вывода отладки, удаление одного из них заставило IDE замерзнуть в течение 30 секунд при выводе отладки, что заставило процесс идти очень медленно.

Я получил нетерпение и написал быстрый и грязный Python script для проверки файлов проекта (Visual Studio  ; 2010) для меня и вывода сразу всех отсутствующих файлов вместе с фильтрами, которые они размещают в Здесь вы можете найти это как Gist: https://gist.github.com/antiuniverse/3825678 (или это которая поддерживает относительные пути)

Пример:

D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
[Header Files]:
  fx_cs_blood.h   (cstrike\fx_cs_blood.h)
  hud_radar.h   (cstrike\hud_radar.h)
[Game Shared Header Files]:
  basecsgrenade_projectile.h   (..\shared\cstrike\basecsgrenade_projectile.h)
  fx_cs_shared.h   (..\shared\cstrike\fx_cs_shared.h)
  weapon_flashbang.h   (..\shared\cstrike\weapon_flashbang.h)
  weapon_hegrenade.h   (..\shared\cstrike\weapon_hegrenade.h)
  weapon_ifmsteadycam.h   (..\shared\weapon_ifmsteadycam.h)
[Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
  basepaenl.h   (swarm\gameui\basepaenl.h)
  ...

Исходный код:

#!/c/Python32/python.exe
import sys
import os
import os.path
import xml.etree.ElementTree as ET

ns = '{http://schemas.microsoft.com/developer/msbuild/2003}'

#Works with relative path also
projectFileName = sys.argv[1]

if not os.path.isabs(projectFileName):
   projectFileName = os.path.join(os.getcwd(), projectFileName)

filterTree = ET.parse(projectFileName+".filters")
filterRoot = filterTree.getroot()
filterDict = dict()
missingDict = dict()

for inc in filterRoot.iter(ns+'ClInclude'):
    incFileRel = inc.get('Include')
    incFilter = inc.find(ns+'Filter')
    if incFileRel != None and incFilter != None:
        filterDict[incFileRel] = incFilter.text
        if incFilter.text not in missingDict:
            missingDict[incFilter.text] = []

projTree = ET.parse(projectFileName)
projRoot = projTree.getroot()

for inc in projRoot.iter(ns+'ClInclude'):
    incFileRel = inc.get('Include')
    if incFileRel != None:
        incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
        if not os.path.exists(incFile):
            missingDict[filterDict[incFileRel]].append(incFileRel)

for (missingGroup, missingList) in missingDict.items():
    if len(missingList) > 0:
        print("["+missingGroup+"]:")
        for missing in missingList:
            print("  " + os.path.basename(missing) + "   (" + missing + ")")

Ответ 6

Я удалил cpp и некоторые файлы заголовков из решения (и с диска), но все еще имел проблему.

Thing - каждый файл, который использует компилятор, находится в файле *.tlog в вашем каталоге temp. Когда вы удаляете файл, этот *.tlog файл не обновляется. Чтобы файл, используемый инкрементными строками, проверял, обновлен ли ваш проект.

Либо отредактируйте этот .tlog файл вручную, либо очистите проект и перестройте его.

Ответ 7

У меня была аналогичная проблема, но в моем случае отсутствовали файлы, была ошибка в том, как был определен выходной файл pdb: я забыл суффикс .pdb(я обнаружил трюк регистрации отладки).

Чтобы решить проблему, я изменил в файле vxproj следующую строку:

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

к

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

Ответ 8

У меня была эта проблема в VS2013 (обновление 5), и для этого могут быть две причины, которые вы можете найти, включив "Подробный" вывод сборки в разделе "Инструменты" → "Проекты и решения" → "Построить и" Выполнить".

• "Forcing recompile of all source files due to missing PDB "..."
  Это происходит, когда вы отключите вывод информации отладки в своих параметрах компилятора (в разделе "Параметры проекта:" C/С++ "- > " Формат отладочной информации "-" Нет "и" Линкер "- > " Генерировать информацию отладки "до" Нет ":), Если вы оставили" C/С++ "- > " Имя файла базы данных программы "по умолчанию (это" $(IntDir) vc $(PlatformToolsetVersion).pdb "), VS не найдет файл из-за ошибки ( https://connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds).
  Чтобы исправить это, просто очистите имя файла до "" (пустое поле).

• "Forcing rebuild of all source files due to a change in the command line since the last build."
  Кажется, это тоже известная ошибка VS (https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in-the-command-line-since-the-last-build) и, похоже, исправлена ​​в более новых версиях (но не VS2013). Я не знал об обходном пути, но если вы это сделаете, обязательно отправьте его здесь.

Ответ 9

Еще одно простое решение, на которое ссылается Visual Studio Forum.

Изменение конфигурации: меню Инструменты → Параметры → Проекты и решения → Настройки проекта VС++ → Режим обозревателя решений для отображения всех файлов.

Затем вы можете увидеть все файлы в обозревателе решений.

Найдите файлы, отмеченные желтым значком, и удалите их из проекта.

Все в порядке.

Ответ 10

Я не знаю, имеет ли кто-то еще эту проблему, но у моих свойств проекта "Configuration Properties" -> C/C++ -> "Debug Information Format" установлено значение "Нет", и когда я переключил его обратно на "База данных программы (/Zi) по умолчанию", это остановилось проект от перекомпиляции каждый раз.

Ответ 11

Visual Studio 2013 - "Принудительная перекомпиляция всех исходных файлов из-за отсутствия PDB". Я включил подробный вывод сборки, чтобы найти проблему: я включил "Подробный" вывод сборки в разделе "Инструменты" → "Проекты и решения" → "Сборка и запуск".

У меня было несколько проектов, все С++, я установил параметр для параметров проекта: (C/С++ → Отладочный информационный формат) в базу данных программы (/Zi) для проблемного проекта. Однако это не остановило проблему для этого проекта. Проблема возникла из одного из других проектов С++ в решении.

Я установил все проекты на С++ в "Program Database (/Zi)". Это устранило проблему.

Опять же, проект, сообщающий о проблеме, не был проблемным проектом. Попробуйте настроить все проекты на "Program Database (/Zi)", чтобы устранить проблему.

Ответ 12

Сегодня я встретил эту проблему, но это было немного иначе. У меня был проект CUDA DLL в моем решении. Компиляция в чистом решении была в порядке, но в противном случае она не удалась, и компилятор всегда рассматривал проект CUDA DLL как не обновленный.

Я попробовал решение из этого сообщения.

Но в моем решении отсутствует файл заголовка. Тогда я выяснил причину в моем случае.

Я раньше менял проект Intermediate Directory, хотя это не вызывало проблем. И теперь, когда я изменил проект промежуточного каталога проекта CUDA DLL обратно на $(Конфигурация) \, все снова работает правильно.

Я предполагаю, что существует небольшая проблема между настройкой CUDA Build Customization и промежуточным каталогом промежуточного уровня.

Ответ 13

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

Вот моя история:

• Под Windows 7 файл находится в %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. Есть два похожих файла devenv.exe.config.config и devenv.exe.config. Вы хотите изменить позже один.

• В Windows 7 у вас нет разрешения на редактирование этого файла в файлах программы. Просто скопируйте его в другое место (рабочий стол), изменив его, а затем скопируйте обратно в расположение файлов программ.

• Я пытался выяснить, как подключить DebugView к IDE, чтобы увидеть отсутствующие файлы. Ну, вам не нужно ничего делать. Просто запустите его, и он захватит все сообщения. Убедитесь, что в меню Capture выбрано меню Capture Events, которое по умолчанию должно быть выбрано.

• DebugView НЕ будет отображать все недостающие файлы сразу (по крайней мере, это не для меня)! У вас будет запуск DebugView и запуск проекта в Visual Studio 2010. Появится сообщение project out of date, выберите "Да" для сборки, а DebugView покажет первый файл, который отсутствует или вызывает перестройку. Откройте файл проекта (не файл решения) в Блокноте и найдите этот файл и удалите его. Вы лучше закрываете свой проект и снова открываете его, делая это удаление. Повторите этот процесс, пока DebugView больше не покажет, какие файлы отсутствуют.

• Очень полезно настроить фильтр сообщений не в актуальном состоянии с помощью панели инструментов DebugView или Edit → Filter/Highlight. Таким образом, единственные сообщения, которые он отображает, - это тот, у которого в нем есть "не обновленная" строка.

У меня было много файлов, которые были ненужными ссылками, и их устранение устраняло проблему, описанную выше.

Второй способ сразу найти все недостающие файлы

Существует второй способ найти эти файлы сразу, но он включает (a) источник управления и (б) интеграцию его с Visual Studio 2010. Используя Visual Studio 2010, добавьте проект в нужное место или фиктивное местоположение в исходном элементе управления. Он попытается добавить все файлы, в том числе те, которые еще не существуют на диске, но указаны в файле проекта. Перейдите в свое программное обеспечение для управления версиями, например Perforce, и оно должно пометить эти файлы, которые не существуют на диске в другой цветовой схеме. Perforce показывает их с черным замком на них. Это ваши недостающие ссылки. Теперь у вас есть список всех них, и вы можете удалить их из своего файла проекта с помощью "Блокнота", и ваш проект не будет жаловаться на устаревание.

Ответ 14

Для меня это было присутствие несуществующего файла заголовка в "Заголовочных файлах" внутри проекта. После удаления этой записи (щелчок правой кнопкой мыши > Исключить из проекта) сначала перекомпилирован, а затем непосредственно

========== Build: 0 удался, 0 не удалось, 5 обновлено, 0 пропущено ==========

и никаких попыток восстановления без изменений не было сделано. Я думаю, это проверка перед сборкой, реализованная VS2010 (не уверен, если она будет документирована, может быть), которая запускает флаг "AlwaysCreate".

Ответ 15

Если вы используете командную строку MSBuild (не Visual Studio IDE), например, если вы нацеливаете AppVeyor или просто предпочитаете командную строку, вы можете добавить эту опцию в свою командную строку MSBuild:

/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8

Как описано здесь (предупреждение: обычная многословия MSDN). Когда сборка завершается, найдите строку will be compiled в файле журнала, созданном во время сборки, MyLog.log.

Ответ 16

Я использую Visual Studio 2013 Professional с Update 4, но не нашел разрешения с любыми другими предложениями, однако мне удалось решить проблему для моего проекта Team.

Вот что я сделал, чтобы вызвать проблему -

• Создал новый объект класса (Project → Add Class)
• Переименовал файл через Solution Explorer и нажал "да", когда его спросили, хочу ли я автоматически переименовать все ссылки для соответствия

Вот что я сделал для решения проблемы -

• Перейти к Team Explorer Home
• Нажмите "Проводник управления источниками"
• Вставьте папку, в которой все файлы класса/проекта
• Найденное ORIGINAL имя файла в списке и удалил его, щелкнув правой кнопкой мыши
• Построить

Если это так, то просто убедитесь, что вы удаляете файл phantom, а не тот, который вы хотите сохранить в проекте.

Ответ 17

У меня была эта проблема и нашла это:

http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

Проект Visual С++ постоянно устарел (winwlm.h macwin32.h rpcerr.h macname1.h отсутствует)

Проблема:

В Visual С++.Net 2003 один из моих проектов всегда утверждал, что устарел, хотя ничего не изменилось и в последней сборке не было сообщений об ошибках.

Открытие файла BuildLog.htm для соответствующего проекта показало список ошибок PRJ0041 для этих файлов, ни один из которых не отображается в моей системе нигде: winwlm.h macwin32.h rpcerr.h macname1.h

Каждая ошибка выглядит примерно так:

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.  

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

Решение:

Включить afxres.h вместо resource.h внутри файла проекта .rc.

Файл проекта .rc содержит "#include resource.h". Поскольку компилятор ресурсов не соблюдает препроцессорные блоки #ifdef, он прорвется и попытается найти включенные файлы, которые он должен игнорировать. Windows.h содержит много таких блоков. В том числе afxres.h вместо этого исправили предупреждения PRJ0041 и устранили диалоговое окно ошибки "Проект устарел".

Ответ 18

В моем случае один из проектов содержит несколько файлов IDL. Компилятор MIDL создает файл данных DLL с именем 'dlldata.c' для каждого из них, независимо от имени файла IDL. Это заставило Visual Studio скомпилировать файлы IDL в каждой сборке, даже без изменений в любом из файлов IDL.

Обходной путь заключается в настройке уникального выходного файла для каждого файла IDL (компилятор MIDL всегда генерирует такой файл, даже если переключатель /dlldata опущен):

• Щелкните правой кнопкой мыши файл IDL
• Выбрать свойства - MIDL - выход
• Введите уникальное имя файла для свойства файла DllData​​li >

Ответ 19

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

Ответ 20

Существует немало потенциальных причин, и, как уже отмечалось, вам нужно сначала диагностировать их, установив многословие MSBuild в "Диагностика". В большинстве случаев заявленная причина была бы самоочевидной, и вы могли бы действовать сразу же, но иногда MSBuild ошибочно утверждал, что некоторые файлы изменены и их нужно скопировать.

Если это так, вам нужно либо отключить туннелирование NTFS, либо дублировать вашу выходную папку на новое место. Вот несколько слов.

Ответ 21

Для меня проблема возникла в проекте WPF, где у некоторых файлов было установлено свойство "Свойство действия" для "Ресурс", а их "Копировать в выходной каталог" - "Копировать, если новый". По-видимому, решение заключалось в том, чтобы изменить свойство "Копировать в выходной каталог" на "Не копировать".

msbuild знает, что не нужно копировать файлы "Resource" на выход, но все же запускает сборку, если их там нет. Может быть, это можно считать ошибкой?

Это очень полезно с ответами здесь, намекая, как получить msbuild, чтобы разлить beans о том, почему он продолжает строить все!

Ответ 22

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

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

Ответ 23

У меня была аналогичная проблема с 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/С++, так и компоновщик соответствует местоположению, используемому другими рабочими проектами. Я также переключил RTTI на.

Ответ 24

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

Ответ 25

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

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

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

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

Ответ 26

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

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

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

Теперь вернемся к нормальному поведению.

Ответ 27

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

Ответ 28

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