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. Добавьте следующую строку после :

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

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

    (Я просто нажал Ctrl + F и искал not up to date ). Это будут ссылки, приводящие к тому, что проект будет постоянно «устаревшим».

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

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

      

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

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

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

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

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

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

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

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

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

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

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

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

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

Я получил нетерпение и написал быстрый и грязный скрипт Python для проверки файлов проекта (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 + ")") 

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

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

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

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

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

 MyName 

в

 MyName.pdb 

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

  1. "Forcing recompile of all source files due to missing PDB "..."
    Это происходит, когда вы отключите вывод информации отладки в своих параметрах компилятора (в разделе «Параметры проекта:« C / C ++ »->« Формат отладочной информации »-« Нет »и« Линкер »->« Генерировать информацию отладки »до« Нет »:) , Если вы оставили «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- from -the-last-build ) и, похоже, исправлена ​​в более новых версиях (но не VS2013). Я не знал об обходном пути, но если вы это сделаете, обязательно отправьте его здесь.

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

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

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

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

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

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

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

Я попробовал решение с этой должности .

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

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

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

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

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

  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 выбрано меню « Capture Events которое по умолчанию должно быть выбрано.

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

  5. Очень полезно настроить фильтр сообщений не в актуальном состоянии с помощью панели инструментов DebugView или EditFilter / Highlight . Таким образом, единственные сообщения, которые он отображает, – это тот, у которого в нем есть «не обновленная» строка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня была эта проблема, и я нашел следующее:

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

Проект Visual C ++ постоянно устаревает ( winwlm.h macwin32.h rpcerr.h macname1.h отсутствует 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, либо дублировать вашу выходную папку в новое место. Вот несколько слов.

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

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

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

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

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

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

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

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

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

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

У меня была аналогичная проблема с 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 SP3, но я столкнулся с аналогичной проблемой на Visual Studio 2013 несколько лет назад.

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

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

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

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

  • Ограничения на установку расширений или надстроек в Visual Studio 2010 Express
  • Комбинация смешанного режима построена против версии «v2.0.50727» среды выполнения
  • C ++ Fatal Error LNK1120: 1 нерешенные внешние
  • Visual Studio 2010 не удается установить с помощью «Ошибка при установке»
  • Тип или имя пространства имен «DbContext» не удалось найти
  • Повреждение кучи при использовании CreateWindowExW
  • Как отлаживать один stream в Visual Studio?
  • Настройка VS Intellisense для вызовов ядра CUDA
  • Преобразование Web.config работает локально
  • представление ловушки
  • Смешивание отладки и выпуска библиотеки / двоичного кода - неправильная практика?
  • Давайте будем гением компьютера.