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

Question

Я перенес решение с VS2008 на VS2010 (SP1).
Теперь один из моих проектов никогда не находит мир в обновлении.Каждая сборка имеет следующий вывод:

1>------ Build started: Project: PROJ_NAME, Configuration: Release Win32 ------
1>Build started 19/05/2011 7:59:27 AM.
1>InitializeBuildStatus:
1>  Creating "Release\PROJ_NAME.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1>  All outputs are up-to-date.
1>  All outputs are up-to-date.
1>Lib:
1>  All outputs are up-to-date.
1>  PROJ_NAME.vcxproj -> C:\projFolder.PROJ_NAME.lib
1>FinalizeBuildStatus:
1>  Deleting file "Release\PROJ_NAME.unsuccessfulbuild".
1>  Touching "Release\PROJ_NAME.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.09
========== Build: 1 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========

Есть идеи?

Answer 1

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

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

Answer 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" />

Answer 3

Согласно этому потоку в MSDN:

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

Вы также можете обнаружить, что это происходит после обновления Windows: Обновленные проекты, скомпилированные заново из-за отметки даты TZRE.DLL в будущем после обновления Windows

решение состоит в том, чтобы подождать до этого времени, и проблема волшебным образом исчезнет.У меня просто была такая же проблема, мой файл TZRES.DLL 17/07/2018 19:54, сейчас время 17/07/2018 15: 15

Answer 7

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

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

Примечание. Вывод можно передать в файл с помощью msbuild.exe / verbosity: подробный> 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:

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

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

Решение: переключить режим Debug / Release с 32-битного на 64-битный или наоборот

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