我已将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 ==========
有什么想法吗?
答案 0 :(得分:40)
当项目中列出的其中一个包含文件实际上不存在时,我遇到了类似的问题。我删除了该文件,但忘记将其从项目中删除。
依赖检查器然后认为项目不是最新的,但构建器找不到任何构建。
答案 1 :(得分:34)
我有两个包含相同文件的项目。构建第二个项目时,它会再次编译文件,更改“触摸”日期时间。这又为第一个项目设置了'AlwaysCreate'标志。
我通过打开“C:\ Program Files(x86)\ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ devenv.exe.config”文件中的“CPS”找到了这个,就像下面的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" />
答案 2 :(得分:9)
根据MSDN上的this帖子:
在VS10的情况下,它是由于项目文件夹中缺少(但未编译的.h文件,因此无需识别其他错误)。
快速检查所有项目文件是否可以在编辑器中打开修复此问题。
答案 3 :(得分:2)
您还必须检查除.h之外的其他文件。在我的项目中,错过了Readme.txt。
答案 4 :(得分:2)
我将解决方案移动到一个新文件夹,每次我构建新版本或尝试调试时,它都会声称构成解决方案的所有项目都已过时,即使它刚刚构建它们。
我搜索了所有的.vcxproj文件,使用了CPS = 4的DebugView(参见上面的@Bzzt的回答)并发现它正在寻找OLD位置的头文件。由于解决方案已移动而未复制,因此这些文件不存在。
最终为我解决的是清理解决方案并进行一次重建。之后,“AlwaysCreate”不再导致它“构建”所有子项目。你必须单独清理每个配置(调试和发布),但是一旦从干净状态重建它,一切都很好。
在我的情况下,它实际上没有做任何构建,但MSBuild或任何决定的东西已经过时,使用了一些不再存在的缓存文件路径。 Clean和Rebuild替换了该缓存,然后像预期的那样构建
答案 5 :(得分:0)
答案 6 :(得分:0)
在Visual Studio 2010中,我通过不设置多处理器编译(/ MP)来消除多项目解决方案的虚假重建(可惜!)。以前,我启用了它。在此处找到标志:Common Properties&gt; C / C ++&gt;一般&gt;多处理器编译。此外,我注意到我能够通过单独重建每个项目来消除个别项目的虚假重建;然后每个的构建显示每个都是最新的。
答案 7 :(得分:0)
为了实现这一点,我只是重命名了我现有的输出目录,以便重新创建所有中间文件(在尝试了所有上述接受的答案之后)。
我过去使用VS2010中的DebugView来查找要删除的文件,但今天这种方法不起作用。在我的任何代码或项目文件XML中,我都找不到使用DebugView找到的缺少头文件的任何引用。我还从TFS中检索过时的文件,尝试在我的机器上存在和不存在它们。
然后我使用GREP搜索我的整个解决方案目录,唯一的结果是二进制文件:旧代码文件'* .obj,项目文件的* .pdb和vc100.idb。我不知道在构建和重建期间如何修改/替换这些文件,所以我不确定其中一个文件中的先前引用是否负责声称旧的头文件丢失。
希望这可以帮助有人在路上,并感谢上面的信息让我开始了!
答案 8 :(得分:0)
对于命令行msbuild.exe构建,您可以使用/ verbosity:detailed并搜索输出
注意:可以使用 msbuild.exe / verbosity将输出传送到文件:详细&gt; output.txt的
e.g。
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:
答案 9 :(得分:0)
在Windows更新后,您可能还会发现这种情况:logical indexing
解决方案是等到那个时候,问题就会神奇地消失。 我只是遇到了同样的问题,我的TZRES.DLL文件是17/07/2018 19:54,现在的时间是17/07/2018 15:15