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

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

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

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

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

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

Любые другие идеи, почему Visual Studio 2010 ведет себя так?

Только для Visual Studio / Express 2010. Смотрите другие (более простые) ответы для VS2012, VS2013 и т. Д.

Чтобы найти отсутствующие файлы , используйте информацию из статьи « Включение ведения журнала системы проекта C ++», чтобы включить ведение журнала отладки в Visual Studio и просто сообщить, что вызывает перестройку:

1. Откройте devenv.exe.configфайл (находится в %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\или в %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). Для версий Express файл конфигурации имеет имя V*Express.exe.config.

2. Добавьте следующее после </configSections>строки:

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

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

6. Поиск в журнале отладки любых строк вида:

   Информация devenv.exe: 0: проект «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>

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

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

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

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

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

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

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

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

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

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

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

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

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

Я потерял терпение и написал быстрый и грязный скрипт Python, чтобы проверить файлы проекта (Visual Studio 2010) для меня и вывести все отсутствующие файлы одновременно, вместе с фильтрами, в которых они находятся. Вы можете найти его как Гист здесь: 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 + ")")

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

Дело в том, что каждый файл, который использует компилятор, помещается в файл * .tlog в вашем временном каталоге. Когда вы удаляете файл, этот файл * .tlog не обновляется. Это файл, используемый инкрементными сборками для проверки актуальности вашего проекта.

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

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

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

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

в

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

У меня была эта проблема в VS2013 (обновление 5), и для этого могут быть две причины, обе из которых можно найти, включив «Подробные» результаты сборки в разделе «Инструменты» -> «Проекты и решения» -> «Построить и запустить» ,

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

2. "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). Я не знаю обходного пути, но если вы сделаете это, обязательно опубликуйте это здесь.

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

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

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

Затем вы можете увидеть все файлы в Solution Explorer.

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

Все нормально.

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

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

Я установил все проекты C ++ на «База данных программ (/ Zi)». Это решило проблему.

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

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

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

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

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

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

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

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

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

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

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

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

5. Полезно установить фильтр сообщений не актуальным с помощью кнопки панели инструментов DebugView или параметра « Правка» → « Фильтр / выделение» . Таким образом, отображаются только те сообщения, в которых есть строка «не в курсе».

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

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

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

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

========== Построение: 0 выполнено, 0 не выполнено, 5 обновлено, 0 пропущено ===========

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

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

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

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

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

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

• Создан новый объект класса (Project -> Add Class)
• Переименовал файл с помощью обозревателя решений и щелкнул «да», когда меня спросили, хочу ли я автоматически переименовать все ссылки для соответствия

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

• Перейти на главную страницу Team Explorer
• Нажмите Source Control Explorer
• Разверните папку, в которой находятся все файлы классов / проектов.
• Нашел ОРИГИНАЛЬНОЕ имя файла в списке и удалил его правой кнопкой мыши.
• Сложение

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

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

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

Visual C ++ Project постоянно устаревший ( winwlm.h macwin32.h rpcerr.h macname1.hотсутствует)

Проблема:

В Visual C ++ .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 и устранено диалоговое окно с сообщением об ошибке «Проект устарел».

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

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

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

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

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

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

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

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

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

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

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

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

Для меня проблема возникла в проекте WPF, где для некоторых файлов свойство «Build Action» было установлено на «Resource», а «Copy to Output Directory» - на «Copy if newer». Казалось, что решением было изменить свойство «Копировать в выходной каталог» на «Не копировать».

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

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

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

У меня была похожая проблема с 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.

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

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

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

Что ж, теперь все вернулось к нормальному поведению.

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

Я нахожусь на Visual Studio 2013 и только что обновил до Windows 10 мая 2019 г. Обновление и компиляция внезапно должны были быть переделаны каждый раз, независимо от изменений. Пробовал переименовывать pch в ProjectName вместо TargetName, искал пропущенные файлы с подробным журналом и этим скриптом Python, но в итоге мое время не синхронизировалось с серверами MS (примерно на миллисекунды).

Что решило это для меня

• «Настройте дату и время» на панели управления
• "Синхронизировать сейчас"

Теперь мои проекты не нужно перекомпилировать без причины.

Я думаю, что вы поместили какой-то символ новой строки или другой пробел. Удалите его и снова нажмите F5.

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