it-roy-ru.com

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 ведет себя так?

191
Chris U

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

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

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

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

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

165
Stanislav

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

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

59
Dave

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

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

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

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

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

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

15
Zach

Принятый ответ помог мне найти правильный путь к решению этой проблемы для испорченного проекта, с которым мне пришлось начать работать. Однако мне пришлось столкнуться с очень большим количеством плохих заголовков include. В результате подробного вывода отладочной информации ее удаление привело к зависанию 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 + ")")
12
Neverender

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

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

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

7
Alexandre Pelletier

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

6
Bim

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

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

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

в

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>
6
JJTh

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

4
paulie4

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

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

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

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

4
user3097514

Другое простое решение, на которое ссылается Visual Studio Forum .

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

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

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

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

4
Christophe

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

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

  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 или Edit Фильтр/Подсветка . Таким образом, отображаются только те сообщения, в которых есть строка "не в курсе".

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

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

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

3
zar

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

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

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

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

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

3
Mass Zhou

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

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

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

2
qris

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

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

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

2
Cristian Amarie

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

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

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

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

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

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

2
Joshua Barker

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

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

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

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

1
avenmore

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

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

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

1
LOAS

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

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

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

1
Mehrdad

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

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

1
Ofek Shilon

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

0
Cathy

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

0
Philip Beck

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

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

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

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

0
Waldemar

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

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

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

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

0
M2X

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

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

0
Chris Becke

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

0
Hinchy