我遇到了与here 描述的非常相似的问题。
我还将 C++/CLI 和 C# 项目的混合解决方案从 Visual Studio 2008 升级到 Visual Studio 2010。现在在 Visual Studio 2010 中，一个 C++/CLI 项目总是过期。
即使它之前已经被编译和链接并且 F5 被点击，消息框“项目已过期。你想构建它吗？”出现。这很烦人，因为 DLL 文件的层级非常低，并且会强制重建解决方案的几乎所有项目。
我的 pdb 设置设置为默认值 (suggested solution of this problem)。
这可能是 Visual Studio 2010 强制重建或认为项目是最新的原因吗？
还有其他关于 Visual Studio 2010 表现如此的想法吗？
【问题讨论】：
标签： visual-studio visual-studio-2010
仅适用于 Visual Studio/Express 2010。查看 VS2012、VS2013 等的其他（更简单的）答案
要找到 the missing file(s)，请使用文章 Enable C++ project system logging 中的信息在 Visual Studio 中启用调试日志记录，并让它告诉你导致重建的原因：
devenv.exe.config 文件（在%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ 或%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ 中找到）。对于 Express 版本，配置文件名为 V*Express.exe.config。在</configSections> 行之后添加以下内容：
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
在调试日志中搜索表单的任何行：
devenv.exe 信息：0：项目“Bla\Bla\Dummy.vcxproj”不是最新的，因为缺少构建输入“Bla\Bla\SomeFile.h”。
（我只是按 Ctrl+F 并搜索 not up to date）这些将是导致项目永久“过时”的引用。
要更正此问题，请从项目中删除对丢失文件的所有引用，或更新引用以指示其实际位置。
注意：如果使用 2012 或更高版本，则 sn-p 应为：
<system.diagnostics>
<switches>
<add name="CPS" value="Verbose" />
</switches>
</system.diagnostics>
【讨论】：
在 Visual Studio 2012 中，我能够比在公认的解决方案中更轻松地获得相同的结果。
我更改了菜单中的选项 Tools → Options → Projects and Solutions → Build and Run → * MSBuild 项目构建输出详细程度“从 Minimal 到 Diagnostic。
然后在构建输出中，我通过搜索“not up to date”找到了相同的行：
“blabla”项目不是最新的。项目项“c:\foo\bar.xml”的“复制到输出目录”属性设置为“始终复制”。
【讨论】：
1>Project not up to date because build input 'C:\...\ReadMe.txt' is missing. :O !!?!
was modified at，因为我没有 not up to date 输出。
今天发生在我身上。我能够找到原因：该项目包含一个不再存在于磁盘上的头文件。
从项目中删除文件解决了这个问题。
【讨论】：
我们也遇到了这个问题，并找到了解决方法。
问题如上所述“磁盘上不再存在该文件。”
这并不完全正确。该文件确实存在于磁盘上，但 .VCPROJ 文件正在其他地方引用该文件。
您可以“发现”这一点，方法是转到“包含文件视图”并依次单击每个包含文件，直到找到 Visual Studio 找不到的那个。然后添加该文件（作为现有项目）并删除找不到的引用，一切正常。
一个有效的问题是：如果 Visual Studio 不知道包含文件的位置，它如何构建？
我们认为 .vcproj 文件在 Visual Studio GUI 中未显示的某处有问题文件的相对路径，这解释了为什么即使包含的树形视图不正确，项目仍会实际构建.
【讨论】：
接受的答案帮助我找到了解决这个问题的正确途径，我不得不开始处理这个搞砸的项目。但是，我不得不处理大量错误的包含标头。对于详细的调试输出，删除一个会导致 IDE 在输出调试喷射时冻结 30 秒，这使得进程非常缓慢。
我不耐烦了，写了一个简单粗暴的 Python 脚本来帮我检查 (Visual Studio 2010) 项目文件，并一次输出所有丢失的文件，以及它们所在的过滤器。你可以找到这里作为要点：https://gist.github.com/antiuniverse/3825678（或这个fork that supports relative paths）
例子：
D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
[Header Files]:
fx_cs_blood.h (cstrike\fx_cs_blood.h)
hud_radar.h (cstrike\hud_radar.h)
[Game Shared Header Files]:
basecsgrenade_projectile.h (..\shared\cstrike\basecsgrenade_projectile.h)
fx_cs_shared.h (..\shared\cstrike\fx_cs_shared.h)
weapon_flashbang.h (..\shared\cstrike\weapon_flashbang.h)
weapon_hegrenade.h (..\shared\cstrike\weapon_hegrenade.h)
weapon_ifmsteadycam.h (..\shared\weapon_ifmsteadycam.h)
[Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
basepaenl.h (swarm\gameui\basepaenl.h)
...
源代码：
#!/c/Python32/python.exe
import sys
import os
import os.path
import xml.etree.ElementTree as ET
ns = '{http://schemas.microsoft.com/developer/msbuild/2003}'
#Works with relative path also
projectFileName = sys.argv[1]
if not os.path.isabs(projectFileName):
projectFileName = os.path.join(os.getcwd(), projectFileName)
filterTree = ET.parse(projectFileName+".filters")
filterRoot = filterTree.getroot()
filterDict = dict()
missingDict = dict()
for inc in filterRoot.iter(ns+'ClInclude'):
incFileRel = inc.get('Include')
incFilter = inc.find(ns+'Filter')
if incFileRel != None and incFilter != None:
filterDict[incFileRel] = incFilter.text
if incFilter.text not in missingDict:
missingDict[incFilter.text] = []
projTree = ET.parse(projectFileName)
projRoot = projTree.getroot()
for inc in projRoot.iter(ns+'ClInclude'):
incFileRel = inc.get('Include')
if incFileRel != None:
incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
if not os.path.exists(incFile):
missingDict[filterDict[incFileRel]].append(incFileRel)
for (missingGroup, missingList) in missingDict.items():
if len(missingList) > 0:
print("["+missingGroup+"]:")
for missing in missingList:
print(" " + os.path.basename(missing) + " (" + missing + ")")
【讨论】：
我已经从解决方案（和磁盘）中删除了一个 cpp 和一些头文件，但问题仍然存在。
问题是，编译器使用的每个文件都放在临时目录中的 *.tlog 文件中。 删除文件时，不会更新此 *.tlog 文件。这是增量构建用来检查您的项目是否是最新的文件。
要么手动编辑此 .tlog 文件，要么清理您的项目并重新构建。
【讨论】：
我遇到了类似的问题，但在我的情况下，没有文件丢失，pdb 输出文件的定义方式出错：我忘记了后缀 .pdb（我通过调试日志记录技巧找到了）。
为了解决我改的问题，在vxproj文件中，下面一行：
<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>
到
<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>
【讨论】：
我在 VS2013（更新 5）中遇到了这个问题，可能有两个原因，您可以通过在“工具”->“项目和解决方案”->“构建”下启用“详细”构建输出来找到这两个原因并运行”。
"Forcing recompile of all source files due to missing PDB "..."
当您在编译器选项中禁用调试信息输出时会发生这种情况（在项目设置下：“C/C++”->“调试信息格式”为“无”和“链接器”->“生成调试信息”为“否”：） .如果您将“C/C++”->“程序数据库文件名”保留为默认值（即“$(IntDir)vc$(PlatformToolsetVersion).pdb”），VS 将由于错误（@ 987654321@).
要修复它，只需将文件名清除为“”（空字段）。
"Forcing rebuild of all source files due to a change in the command line since the last build."
这似乎也是一个已知的 VS 错误（https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in-the-command-line-since-the-last-build），并且似乎在较新的版本中得到了修复（但不是 VS2013）。我知道没有解决方法，但如果你这样做了，请务必在此处发布。
【讨论】：
我不知道其他人是否有同样的问题，但我的项目属性将"Configuration Properties" -> C/C++ -> "Debug Information Format" 设置为“无”，当我将其切换回默认的“程序数据库 (/Zi)”时，它停止了每次重新编译该项目。
【讨论】：
Visual Studio Forum 引用的另一个简单解决方案。
更改配置：菜单工具 → 选项 → 项目和解决方案 → VC++项目设置 → 解决方案资源管理器模式到显示所有文件。
然后您可以在解决方案资源管理器中查看所有文件。
找到标有黄色图标的文件并将它们从项目中删除。
没关系。
【讨论】：
Visual Studio 2013 - “由于缺少 PDB，强制重新编译所有源文件”。我打开了详细的构建输出来定位问题：我在“工具”→“项目和解决方案”→“构建和运行”下启用了“详细”构建输出。
我有几个项目，都是 C++，我为问题项目设置了项目设置下的选项：(C/C++ → 调试信息格式) 到程序数据库 (/Zi)。但是，这并没有阻止该项目的问题。问题来自解决方案中的其他 C++ 项目之一。
我将 所有 C++ 项目设置为“程序数据库 (/Zi)”。这解决了问题。
同样，报告问题的项目不是问题项目。尝试将所有项目设置为“程序数据库（/Zi）”以解决问题。
【讨论】：
我今天遇到了这个问题，但是有点不同。我的解决方案中有一个 CUDA DLL 项目。在干净的解决方案中编译是可以的，但否则它会失败，并且编译器总是将 CUDA DLL 项目视为不是最新的。
我尝试了this post的解决方案。
但我的解决方案中没有丢失的头文件。然后我发现了我的情况的原因。
我之前更改过项目的中间目录，虽然没有造成麻烦。 现在，当我将 CUDA DLL 项目的中间目录改回 $(Configuration)\ 时，一切都恢复正常了。
我猜在 CUDA 构建自定义和非默认中间目录之间存在一些小问题。
【讨论】：
我遇到了类似的问题，并按照上述说明（接受的答案）找到了丢失的文件，但并非没有挠头。这是我所做的总结。准确地说，这些不是丢失的文件，因为项目不需要构建它们（至少在我的情况下），但它们是对磁盘上不存在的文件的引用，这些文件并不是真正需要的。
这是我的故事：
在 Windows 7 下，该文件位于 %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%。有两个类似的文件devenv.exe.config.config 和devenv.exe.config。您想稍后更改。
在 Windows 7 下，您无权编辑程序文件中的此文件。只需将其复制到其他地方（桌面）更改它，然后将其复制回程序文件位置。
我试图弄清楚如何将DebugView 连接到 IDE 以查看丢失的文件。好吧，你不必做任何事情。只需运行它，它将捕获所有消息。确保在Capture 菜单中选择Capture Events 菜单选项，默认情况下应选择该选项。
DebugView 不会一次显示所有丢失的文件（至少它不适合我）！您将运行 DebugView，然后在 Visual Studio 2010 中运行项目。它将提示 project out of date 消息，选择 Yes 进行构建，DebugView 将显示 first 文件丢失或导致重建。在记事本中打开项目文件（不是解决方案文件）并搜索该文件并将其删除。您最好在执行此删除操作时关闭您的项目并重新打开它。重复此过程，直到 DebugView 不再显示任何丢失的文件。
从 DebugView 工具栏按钮或编辑 → 过滤器/突出显示将消息过滤器设置为不是最新的会很有帮助em> 选项。这样，它显示的唯一消息就是其中包含“不是最新”字符串的消息。
我有很多不必要的参考文件，按照上述步骤删除它们都解决了问题。
一次性找到所有丢失文件的第二种方法
还有第二种方法可以一次性找到所有这些文件，但它涉及 (a) 源代码管理和 (b) 将其与 Visual Studio 2010 集成。使用 Visual Studio 2010，添加您的项目到源代码管理中的所需位置或虚拟位置。它将尝试添加所有文件，包括那些不存在于磁盘上但在项目文件中引用的文件。转到您的源代码控制软件，例如Perforce，它应该以不同的配色方案标记这些磁盘上不存在的文件。 Perforce 向他们展示了他们身上的黑色锁。这些是您缺少的参考资料。现在您有了一个全部列表，您可以使用记事本从项目文件中删除所有这些，并且您的项目不会抱怨过时。
【讨论】：
对我来说，项目内部的“头文件”上存在一个不存在的头文件。去掉这个条目后（右键>Exclude from Project）第一次重新编译，然后直接
========== 构建：0 成功，0 失败，5 最新，0 跳过 ==========
并且没有尝试在不修改的情况下进行重建。我认为是 VS2010 实现的构建前检查（不确定是否记录在案），它会触发“AlwaysCreate”标志。
【讨论】：
如果您使用的是命令行 MSBuild 命令（而不是 Visual Studio IDE），例如，如果您以 AppVeyor 为目标，或者您只是更喜欢命令行，则可以将此选项添加到您的 MSBuild 命令行：
/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8
如记录的here （警告：通常的 MSDN 冗长）。构建完成后，在构建过程中创建的日志文件MyLog.log中搜索字符串will be compiled。
【讨论】：
我正在使用带有 Update 4 的 Visual Studio 2013 Professional，但没有找到任何其他建议的解决方案，但是，我确实设法解决了我的团队项目的问题。
这是我造成问题的原因 -
这是我为解决问题所做的 -
如果您遇到这种情况，那么请务必确保您删除的是虚拟文件，而不是您想要保留在项目中的实际文件。
【讨论】：
我遇到了这个问题，发现了这个：
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'.您的项目可能仍会构建，但在找到此文件之前可能会继续显示过期。
解决办法：
在项目的 .rc 文件中包含
afxres.h而不是resource.h。项目的 .rc 文件包含“#include resource.h”。由于资源编译器不支持预处理器
#ifdef块，它会撕开并尝试找到它应该忽略的包含文件。 Windows.h 包含许多这样的块。包括 afxres.h 而是修复了 PRJ0041 警告并消除了“项目已过期”错误对话框。
【讨论】：
在我的例子中，其中一个项目包含多个 IDL 文件。 MIDL 编译器为它们中的每一个生成一个名为“dlldata.c”的 DLL 数据文件，而不管 IDL 文件名如何。这导致 Visual Studio 在每次构建时都编译 IDL 文件，即使没有更改任何 IDL 文件。
解决方法是为每个 IDL 文件配置一个唯一的输出文件（MIDL 编译器总是生成这样一个文件，即使省略了 /dlldata 开关）：
【讨论】：
为此，我花了好几个小时扯头发。构建输出不一致；从一个构建到下一个连续构建，由于不同的原因，不同的项目将“不是最新的”。 我最终发现罪魁祸首是 DropBox (3.0.4)。我将我的源文件夹从 ...\DropBox 连接到我的项目文件夹中（不确定这是否是原因），但 DropBox 以某种方式在构建期间“接触”文件。暂停同步，所有内容始终保持最新状态。
【讨论】：
有很多潜在的原因，并且 - 如前所述 - 您需要首先通过将 MSBuild 详细程度设置为“诊断”来诊断它们。大多数情况下，所陈述的原因是不言自明的，您可以立即采取行动，但有时 MSBuild 会错误地声称某些文件已被修改并需要复制。
如果是这种情况，您需要禁用 NTFS 隧道或将输出文件夹复制到新位置。 Here it is in more words.
【讨论】：
这在我身上发生了很多次，然后在我弄清楚原因之前就消失了。在我的情况下是：
双启动设置中的系统时间错误！
事实证明，我的 Ubuntu 双重启动是根本原因！！我一直懒得修复 Ubuntu 以停止弄乱我的硬件时钟。当我登录 Ubuntu 时，时间向前跳了 5 个小时。
运气不好，我构建了一次项目，系统时间错误，然后更正了时间。结果，所有的构建文件都有错误的时间戳，VS 会认为它们都过时了，会重新构建项目。
【讨论】：
大多数构建系统使用数据时间戳来确定何时应该进行重建 - 任何输出文件的日期/时间戳都会与依赖项的最后修改时间进行检查 - 如果任何依赖项较新，则重新构建目标.
如果任何依赖项以某种方式获得无效的数据时间戳，这可能会导致问题，因为任何构建输出的时间戳都很难超过假定在未来创建的文件的时间戳：P
【讨论】：
对我来说，问题出现在 WPF 项目中，其中一些文件的“构建操作”属性设置为“资源”，并且“复制到输出目录”设置为“如果较新则复制”。解决方案似乎是将“复制到输出目录”属性更改为“不复制”。
msbuild 知道不要将“资源”文件复制到输出 - 但如果它们不存在，仍会触发构建。也许这可以被认为是一个错误？
这里的答案非常有帮助，提示如何让 msbuild 透露为什么它会继续构建所有内容！
【讨论】：
如果您更改项目的调试命令参数，这也会触发项目需要重建消息。即使目标本身不受调试参数的影响，项目属性也已更改。但是，如果您确实进行了重建，则该消息应该会消失。
【讨论】：
我在使用 Visual Studio 2005 时遇到了类似的问题，我的解决方案由以下依赖项中的五个项目组成（首先在顶部构建）：
Video_Codec depends on nothing
Generic_Graphics depends on Video_Codec
SpecificAPI_Graphics depends on Generic_Graphics
Engine depends on Specific_Graphics
Application depends on Engine.
我发现 Video_Codec 项目即使在完全清理然后重新构建解决方案之后也需要完整构建。
我通过确保 C/C++ 和链接器的 pdb 输出文件与其他工作项目使用的位置匹配来解决此问题。我还打开了 RTTI。
【讨论】：
Visual Studio 2015 SP3 上的另一个问题，但几年前我在 Visual Studio 2013 上遇到过类似问题。
我的问题是预编译头文件使用了错误的 cpp 文件（所以我有两个创建预编译头文件的 cpp 文件）。现在为什么 Visual Studio 在没有我的请求的情况下将错误 cpp 上的标志更改为“创建预编译头”我不知道，但它确实发生了......也许是一些插件或什么？？？
无论如何，错误的 cpp 文件包括 version.h 文件，该文件在每次构建时都会更改。因此 Visual Studio 会重新构建所有头文件，并因此重新构建整个项目。
嗯，现在又恢复正常了。
【讨论】：
我有一个始终编译所有文件的 VC++ 项目，并且之前已从 VS2005 升级到 VS2010（由其他人）。我发现项目中除了 StdAfx.cpp 之外的所有 cpp 文件都设置为 Create (/Yc) the precompiled header。我对此进行了更改，因此仅将 StdAfx.cpp 设置为创建预编译头文件，其余设置为使用 (/Yu) 预编译头文件，这为我解决了问题。
【讨论】：
我在 Visual Studio 2013 上，刚刚更新到 Windows 10 May 2019 更新和编译突然不得不每次重做，无论更改如何。尝试将 pch 重命名为 ProjectName 而不是 TargetName，使用详细日志和 Python 脚本查找丢失的文件，但最后是我的时间没有与 MS 的服务器同步（大约毫秒）。
为我解决这个问题的是
现在我的项目不需要无缘无故重新编译了。
【讨论】：
我认为您放置了一些换行符或其他空格。删除它并再次按 F5。
【讨论】：
无论如何，.NET 项目总是会重新编译。其中一部分是为了使 IDE 保持最新（例如 IntelliSense）。我记得几年前在微软论坛上问过这个问题，这就是我得到的答案。
【讨论】：