Visual Studio: проект не обновлен ", потому что" AlwaysCreate "был указан"?

Ответ 1

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

Затем проверка зависимостей полагает, что проект не обновлен, но строитель ничего не находит для сборки.

Ответ 2

У меня было два проекта, содержащих один и тот же файл. Когда второй проект был построен, он снова скомпилировал файл, изменив дату и время касания. Это, в свою очередь, установило флаг "AlwaysCreate" для первого проекта.

Я нашел это, включив "CPS" в моем файле "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config", как в приведенном ниже фрагменте xml. С помощью этой функции вы можете использовать инструмент DebugView для получения сообщений от VS2010, в которых указывается, ПОЧЕМУ он перестраивает ваш проект. Почему эти сообщения не входят в журнал сборки, выходят за меня, но в любом случае это так.

Добавьте это:

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

Здесь:

<?xml version ="1.0"?>
<configuration>
    <configSections>
        <section name="msbuildToolsets" type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </configSections>
    <system.diagnostics>
      <switches>
        <add name="CPS" value="4" />
      </switches>
    </system.diagnostics>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0.30319" />

Ответ 3

В соответствии с этим потоком в MSDN:

В моем случае в VS10 это произошло из-за отсутствия (но не выполнимых файлов .h, а значит, дополнительной ошибки для идентификации) в папках проекта.

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

Ответ 4

Вы также должны проверить другие файлы, кроме .h. В моем проекте Readme.txt был пропущен.

Ответ 5

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

Я искал все файлы .vcxproj, использовал DebugView с CPS = 4 (см. ответ @Bzzt выше) и обнаружил, что он ищет файлы заголовков в своем OLD-местоположении. Поскольку решение было перемещено, а не скопировано, эти файлы не существовали.

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

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

Ответ 6

У меня такая же проблема.

Корневая причина: неверная версия сборки VS (32 бит и 64 бит)

Решение: Режим переключения Отладка/отключение с 32 до 64 бит или наоборот

http://postimg.org/image/3jurey1qr/

Ответ 7

В Visual Studio 2010 я исключил ложные перестройки многопроектного решения, оставив Multiprocessor Compilation (/MP) отключенным (жалость!). Раньше я был включен. Найдите здесь флаг: Общие свойствa > C/С++ > Общие > Многопроцессорная компиляция. Кроме того, я заметил, что я смог устранить ложные перестройки отдельных проектов, перестраивая каждый проект индивидуально; то каждая из них показывала, что каждый из них обновлен.

Ответ 8

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

У меня был успех в прошлом с использованием DebugView в VS2010, чтобы найти файлы для удаления, но сегодня этот подход не сработал. Я не мог найти ЛЮБОЙ ссылки на отсутствующие файлы заголовков, найденные с использованием DebugView, в любом из моих файлов кода или файлов проекта XML. Я также извлек устаревшие файлы из TFS, чтобы попытаться с ними присутствовать и отсутствовать на моей машине.

Затем я использовал GREP для поиска всей моей директории решений, и единственные результаты были в двоичных файлах: старые файлы кода *.obj, файл проекта *.pdb и vc100.idb. Я не знаю, как эти файлы могут быть изменены/заменены во время сборки и перестройки, поэтому я не уверен, что предыдущая ссылка в одном из этих файлов была ответственна за утверждение старых файлов заголовков.

Надеюсь, это поможет кому-то по дороге, и спасибо за приведенную выше информацию, которая заставила меня начать!

Ответ 9

Для командной строки сборки msbuild.exe вы можете использовать /verbosity: подробно и искать вывод для

• "будет скомпилирован как" найти компиляции
• "Требуется исходная компиляция" для поиска ссылок

Примечание. Вывод может быть передан в файл с помощью msbuild.exe/verbosity: detail > output.txt

например.

code.cpp will be compiled as C:\path\to\header.h was modified at 18/02/2016 15:58:31.
Outputs for C:\path\to\code.cpp: