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" має атрибут "Copy to Output Directory", встановлений на "Copy always".

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

Видалення файлу з проекту вирішило проблему.

Ми також зіткнулися з цим питанням і з’ясували, як його вирішити.

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

Це не зовсім правильно. Файл існує на диску, але файл .VCPROJ посилається на файл десь інше.

Ви можете "відкрити" це, перейшовши до "включити перегляд файлу" і натискаючи по черзі кожен файл включення, поки не знайдете той, який Visual Studio не може знайти. Потім ви додасте цей файл (як існуючий елемент) і видаляєте посилання, яке неможливо знайти, і все гаразд.

Правильне питання: Як Visual Studio навіть може будувати, якщо він не знає, де містяться файли?

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

Прийнята відповідь допомогла мені правильно зрозуміти, як вирішити цю проблему для закрученого проекту, з яким мені довелося почати працювати. Однак мені довелося зіткнутися з дуже великою кількістю заголовків поганих включень. Завдяки багатослівному виведенню налагодження, видалення змусило 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- командний рядок-з-за-останній збірки ) і, здається, виправлений у новіших версіях (але не VS2013). Я не знав жодного вирішення, але якщо ви все-таки допишіть його тут.

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

Ще одне просте рішення, на яке посилається Visual Studio Forum .

Зміна конфігурації: меню Інструменти → Опції → Проекти та рішення → Налаштування проекту VC ++ → Режим провідника рішень для відображення всіх файлів .

Тоді ви можете побачити всі файли в Провіднику рішень.

Знайдіть файли, позначені жовтим значком, і видаліть їх із проекту.

Нічого страшного.

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

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

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

Знову ж таки, проект, що повідомляє про проблему, не був проблемним проектом. Спробуйте встановити всі проекти на "База даних програми (/ Zi)", щоб вирішити проблему.

Я зіткнувся з цією проблемою сьогодні, проте це було трохи інакше. У мене був проект DLL CUDA. Компіляція в чистому розчині була в порядку, але в іншому випадку не вдалося, і компілятор завжди ставився до DLL-проекту CUDA як до сучасного.

Я спробував рішення з цієї посади .

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

Я раніше змінював проміжний каталог проекту, хоча це не викликало проблем. І тепер, коли я змінив проміжний каталог проекту CUDA DLL назад на $ (конфігурація) \, все працює знову правильно.

Напевно, є якась незначна проблема між налаштуваннями CUDA Build Buildings та проміжним каталогом, що не використовується за замовчуванням.

У мене була подібна проблема, і я дотримувався вищевказаних інструкцій (прийнята відповідь), щоб знайти відсутні файли, але не без подряпин по голові. Ось мій підсумок того, що я зробив. Для точності це не пропущені файли, оскільки проект не потрібен для створення (принаймні, в моєму випадку), але це посилання на файли, які не існують на диску, які насправді не потрібні.

Ось моя історія:

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 , і він має позначити ці файли, які не існують на диску в іншій кольоровій гамі. Перфорс показує їх із чорним замком на них. Це ваші пропущені посилання. Тепер у вас є список їх усіх, і ви можете видалити їх із файлу проекту за допомогою блокнота, і ваш проект не скаржиться на застарілість .

Для мене це була наявність неіснуючого файлу заголовка на "Файлах заголовка" всередині проекту. Після видалення цього запису (клацніть правою кнопкою миші> Виключити з проекту) спочатку перекомпілюйте, а потім безпосередньо

========== Збірка: 0 вдалося, 0 не вдалося, 5 оновлено, 0 пропустило ==========

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

Якщо ви використовуєте командний рядок команди MSBuild (а не ID ID 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, але не знайшов вирішення жодної з інших пропозицій, проте мені вдалося вирішити проблему для мого командного проекту.

Ось що я зробив, щоб викликати проблему -

• Створено новий об’єкт класу (Проект -> Додати клас)
• Перейменував файл через Explorer Explorer і натиснув так, коли мене запитали, чи хочу я автоматично перейменовувати всі посилання на відповідність

Ось що я зробив, щоб вирішити проблему -

• Перейдіть до Домашньої програми Explorer
• Клацніть Провідник управління джерелами
• Ознайомтеся з папкою, де знаходяться всі файли класу / проекту
• Знайдено ім’я ORIGINAL у списку та видалило його правою кнопкою миші
• Побудувати

Якщо це так, то просто будьте впевнені, що ви видаляєте фантомний файл, а не фактичний, який ви хочете зберегти в проекті.

У мене була ця проблема і було виявлено таке:

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 та усунено діалогове вікно помилок "Проект застарів".

У моєму випадку один із проектів містить кілька файлів 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 moreer". Здається, рішенням було змінити властивість "Копіювати у каталог виводу" на "Не копіювати".

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

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

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

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

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

Я перебуваю на Visual Studio 2013 і щойно оновлений до оновлення та компіляції Windows 10 травня 2019 року раптом доводилося щоразу переробляти, незалежно від змін. Спробував перейменувати pch на ProjectName замість TargetName, шукав відсутні файли з докладним журналом і тим сценарієм Python, але врешті-решт мій час не був синхронізований із серверами MS (на зразок мілісекунд).

Що для мене це вирішило

• "Налаштування дати та часу" на панелі керування
• "Синхронізувати зараз"

Тепер мої проекти не потрібно перекомпілювати без причини.

Я думаю, що ви розмістили якусь нову лінію чи іншу пробіл. Вийміть його та натисніть F5 ще раз.

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