Visual Studio：项目不是最新的“因为指定了“AlwaysCreate””？答案

【问题标题】：Visual Studio: project is not up to date "because "AlwaysCreate" was specified"?Visual Studio：项目不是最新的“因为指定了“AlwaysCreate””？
【发布时间】：2011-08-28 14:02:24
【问题描述】：

我已将解决方案从 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 ==========

有什么想法吗？

【问题讨论】：

Visual studio 2010 build problems 的可能重复项
尝试将整个项目复制到不同的位置，同时确保删除对不存在的文件（如 .h 文件）的所有引用，并让我们知道结果。也请查看此页面：connect.microsoft.com/VisualStudio/feedback/details/574245/…
@als 类似的输出，没问题。但是，确实是stackoverflow.com/questions/2762930/… 的重复。抱歉，搜索 because "AlwaysCreate" was specified 没有给出正确的结果，所以我想我会保持打开状态...
当然没问题，如果可能的重复不能解决您的问题，确实是另一个问题，您应该保持打开状态。不用担心:)

标签： c++ visual-studio visual-studio-2010 visual-studio-2015 msbuild

【解决方案1】：

当项目中列出的包含文件之一实际上不存在时，我遇到了类似的问题。我已删除该文件，但忘记将其从项目中删除。

然后依赖检查器认为项目不是最新的，但构建器没有发现要构建的东西。

【讨论】：

谢谢。我的一个标题丢失了。
有一个很好的插件可以显示错误列表中丢失的文件：visualstudiogallery.msdn.microsoft.com/…
@koch.trier 除了这个插件不支持VS2010。
这个。在 VS2015 中也是如此。提到plugin 创造奇迹。旁注：VS2015 中缺少的头文件实际上很容易找到，因为 VS2015 为解决方案资源管理器中的每个现有文件添加了一个“▷”，但我的项目也缺少旧的资源文件条目（删除了 bmp 文件）和插件也得到这些。
万一其他人遇到这种情况：这很明显，但是如果您将 系统时钟 更改为及时返回（无论出于何种原因），那么这将导致“永远创造”的局面。 @koch.trier 提到的插件显示了各种虚假的 CMake 生成文件，这让我大吃一惊。这种情况下的解决方案是修复系统时钟，和/或触摸所有文件以修复它们的时间戳。

【解决方案2】：

我有两个项目包含相同的文件。当第二个项目构建时，它再次编译文件，更改“触摸”日期时间。这反过来又为第一个项目设置了“AlwaysCreate”标志。

我通过在“C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config”文件中打开“CPS”发现了这一点，如下面的 xml sn-p .激活后，您可以使用 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" />

【讨论】：

在黑暗时期非常有用（当你开始给某个比尔起额外的名字时......）。
我推荐这个！在几分钟内，我就能够使用 DebugView 发现一些有问题的文件，并且在我从事的项目中，构建时间减少了 15%。我肯定会为整个项目做这件事，我相信问题更糟:) 编辑：顺便说一句，就像 Bo Persson 所说的那样，所有文件都丢失了，DebugView 只是让找到它们变得容易
这正是我的问题：编译第二个项目，一个应用程序，触发重新编译第一个项目，库。因为他们共享一个预编译的头文件。
对于 VS2012 略有不同：blogs.msdn.com/b/andrewarnottms/archive/2012/06/07/…
@DavidV.Corbin Google 现在发现它是devblogs.microsoft.com/premier-developer/…。

【解决方案3】：

根据MSDN上的this线程：

在我的 VS10 中，这是由于项目文件夹中缺少（但未编译的 .h 文件，因此没有额外的错误可识别）。

快速检查所有项目文件都可以在编辑器中打开解决了这个问题。

【讨论】：

哈哈，这根本不适合大型项目。
您可以使用诊断输出（工具|选项|Z项目和解决方案|构建并运行并使输出诊断。然后搜索“项目不是最新的，因为”甚至“丢失”跨度>

【解决方案4】：

您还必须检查 .h 以外的其他文件。在我的项目中，Readme.txt 被遗漏了。

【讨论】：

【解决方案5】：

我将解决方案移至新文件夹，每次构建新版本或尝试调试时，它都会声称构成该解决方案的所有项目都已过时，即使它刚刚构建他们。

我搜索了所有 .vcxproj 文件，使用了 CPS=4 的 DebugView（参见上面@Bzzt 的答案），发现它正在它们的旧位置寻找头文件。由于解决方案是移动的，而不是复制的，因此这些文件不存在。

最终为我解决的问题是清理解决方案并进行一次重建。之后，“AlwaysCreate”不再导致它“构建”所有子项目。您必须单独清理每个配置（调试和发布），但是一旦从清理状态重建，一切都很好。

在我的情况下，它实际上并没有进行任何构建，但是 MSBuild 或任何已过时的决定，正在使用一些不再存在的缓存文件路径。 Clean and Rebuild 替换了该缓存，然后按预期构建

【讨论】：

+1。修复丢失的文件后，它仍然存在问题，直到我尝试了您的解决方案，尽管我通过删除所有 obj 和 bin 文件夹手动清理。最后，最少的重建工作！

【解决方案6】：

我遇到了同样的问题。

根本原因：VS 的构建版本不正确（32 位和 64 位）

解决方案：将 Debug/Release 模式从 32 位切换到 64 位或反向

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

【讨论】：

【解决方案7】：

在 Visual Studio 2010 中，我通过取消设置多处理器编译 (/MP) 来消除多项目解决方案的虚假重建（可惜！）。以前，我启用了它。在此处找到标志：Common Properties > C/C++ > General > Multi-processor Compilation。此外，我注意到我能够通过单独重建每个项目来消除单个项目的虚假重建。然后每个版本的构建显示每个都是最新的。

【讨论】：

【解决方案8】：

为了让它工作，我只是重命名了我现有的输出目录，以便重新创建所有中间文件（在尝试所有上述接受的答案之后）。

我过去曾在 VS2010 中使用 DebugView 来查找要删除的文件，但今天这种方法不起作用。在我的任何代码或项目文件 XML 中，我找不到对使用 DebugView 找到的丢失头文件的任何引用。我还从 TFS 中检索了过时的文件，以尝试在我的机器上同时使用它们。

然后我使用 GREP 搜索我的整个解决方案目录，唯一的结果是二进制文件：旧代码文件的 *.obj、项目文件的 *.pdb 和 vc100.idb。我不知道这些文件在构建和重建过程中是如何被修改/替换的，所以我不确定其中一个文件中的先前引用是否负责声称旧的头文件丢失。

希望这对未来的人有所帮助，并感谢上述让我开始的信息！

【讨论】：

【解决方案9】：

对于命令行 msbuild.exe 构建，您可以使用 /verbosity:detailed 并在输出中搜索

“将被编译为”以查找编译
“需要源代码编译”来查找链接

注意：可以使用 msbuild.exe /verbosity:detailed > 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:

【讨论】：

【解决方案10】：

您也可能会在 Windows 更新后发现这种情况，请参阅：Up to date projects compiled again because of TZRE.DLL date stamp is in the future after a windows update

解决办法是等到那个时候，问题就会神奇地消失。我刚遇到同样的问题，我的 TZRES.DLL 文件是 17/07/2018 19:54，现在时间是 17/07/2018 15:15

【讨论】：