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

Question

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

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

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

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

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

Есть еще идеи, почему Visual Studio 2010 ведет себя так?

Answer 1

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

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

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

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

Answer 2

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

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

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 покажет файл first , который отсутствует или вызывает восстановление. Откройте файл проекта (не файл решения) в Блокноте, найдите этот файл и удалите его. Вам лучше закрыть свой проект и снова открыть его во время удаления. Повторяйте этот процесс до тех пор, пока в DebugView больше не исчезнут файлы.

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

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

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