Visual Studio 2010始终认为项目已过时，但未发生任何变化

我有一个非常类似的问题描述在这里。

我还将C ++ / CLI和C＃项目的混合解决方案从Visual Studio 2008升级到了Visual Studio2010。现在在Visual Studio 2010中，一个C ++ / CLI项目总是过期。

即使F5该项目刚刚被编译并链接并被点击，消息框“该项目已过时。您要构建它吗？” 出现。这很烦人，因为DLL文件的层很低，并且迫使解决方案的几乎所有项目都必须重建。

我的pdb设置设置为默认值（此问题的建议解决方案）。

是否有可能得到Visual Studio 2010强制重建或认为项目是最新的原因？

还有其他想法为什么Visual Studio 2010会那样吗？

仅适用于Visual Studio / Express 2010。查看VS2012，VS2013等的其他（更轻松）答案

要查找丢失的文件，请使用文章启用C ++项目系统日志记录中的信息以在Visual Studio中启用调试日志记录，并让它仅告诉您是什么原因导致了重建：

1. 打开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。

2. </configSections>在行之后添加以下内容：

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

3. 重新启动Visual Studio
4. 打开DbgView并确保它捕获调试输出
5. 尝试调试（在Visual Studio中按F5键）

6. 在调试日志中搜索以下格式的任何行：

   devenv.exe信息：0：项目'Bla \ Bla \ Dummy.vcxproj'不是最新的，因为缺少构建输入'Bla \ Bla \ SomeFile.h'。

   （我只是按Ctrl + F并搜索了not up to date）。这些将成为导致项目永久“过时”的引用。

若要更正此问题，请从您的项目中删除对丢失文件的任何引用，或者更新引用以指示其实际位置。

注意：如果使用2012或更高版本，则该代码段应为：

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

与公认的解决方案相比，在Visual Studio 2012中，我能够轻松实现相同的结果。

我将菜单工具 → 选项 → 项目和解决方案 → 生成并运行 →* MSBuild项目生成输出详细程度更改为从最小到诊断。

然后，在构建输出中，通过搜索“不最新”找到相同的行：

项目“ blabla”不是最新的。项目项“ c：\ foo \ bar.xml”的“复制到输出目录”属性设置为“始终复制”。

今天发生在我身上。我能够找到原因：该项目包含一个头文件，该头文件在磁盘上不再存在。

从项目中删除文件解决了该问题。

我们还遇到了这个问题，并找到了解决方法。

问题如上所述，“磁盘上不再存在文件”。

这不是很正确。该文件确实存在于磁盘上，但是.VCPROJ文件正在其他位置引用该文件。

您可以通过转到“包含文件视图”并依次单击每个包含文件来“发现”它，直到找到Visual Studio找不到的文件为止。然后，您添加该文件（作为现有项）并删除找不到的引用，一切正常。

一个有效的问题是：如果Visual Studio不知道包含文件在哪里，该如何构建？

我们认为.vcproj文件在Visual Studio GUI中未显示的地方有指向问题文件的相对路径，这解释了即使includes的树视图不正确，项目仍会真正构建的原因。

被接受的答案帮助我找到了正确的途径，以解决如何为不得不开始的搞砸项目解决这个问题。但是，我不得不处理大量错误的头文件。对于冗长的调试输出，删除调试输出会导致IDE在输出调试启动时冻结30秒，这会使该过程非常缓慢。

我很不耐烦，并编写了一个快速且肮脏的Python脚本来为我检查（Visual Studio 2010）项目文件，并一次输出所有丢失的文件以及它们所在的过滤器。要点在这里：https : //gist.github.com/antiuniverse/3825678（或支持相对路径的此fork）

例：

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和一些头文件，但是仍然有问题。

事实是，编译器使用的每个文件都放在temp目录中的* .tlog文件中。删除文件时，此* .tlog文件不会更新。这是增量构建用于检查您的项目是否最新的文件。

手动编辑此.tlog文件，或清理项目并重建。

我有一个类似的问题，但是在我的情况下，没有文件丢失，pdb输出文件的定义方式出错：我忘记了后缀.pdb（我发现了调试日志记录技巧）。

为了解决我更改的问题，在vxproj文件中，以下行：

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

至

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

我在VS2013（更新5）中遇到了这个问题，可能有两个原因，您都可以通过在“工具”->“项目和解决方案”->“构建并运行”下启用“详细”构建输出来找到这两个原因。

1. "Forcing recompile of all source files due to missing PDB "..."
   在禁用编译器选项中的调试信息输出时会发生这种情况（在项目设置下：“ C / C ++”->“调试信息格式”为“无”，而“链接器”->“生成调试信息”为“否” ：） 。如果默认情况下保留“ C / C ++”->“程序数据库文件名”（即“ $（IntDir）vc $（PlatformToolsetVersion）.pdb”），则由于错误（https，VS将找不到该文件：//connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds）。
   要解决此问题，只需将文件名清除为“”（空字段）。

2. "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- ，因为它在最新版本中已修复（但未在VS2013中修复）。我知道没有解决方法，但是如果可以的话，请在此处发布。

我不知道是否有人遇到相同的问题，但是我的项目的属性已"Configuration Properties" -> C/C++ -> "Debug Information Format"设置为“无”，并且当我将其切换回默认的“程序数据库（/ Zi）”时，每次都使项目无法重新编译。

Visual Studio论坛引用的另一个简单解决方案。

更改配置：菜单工具 → 选项 → 项目和解决方案 → VC ++项目设置 → 解决方案资源管理器模式以显示所有文件。

然后，您可以在解决方案资源管理器中查看所有文件。

找到带有黄色图标标记的文件，并将其从项目中删除。

没关系。

Visual Studio 2013-“由于缺少PDB而强制重新编译所有源文件”。我打开了详细的构建输出以查找问题：我在“工具”→“项目和解决方案”→“构建并运行”下启用了“详细”构建输出。

我有几个项目，都是C ++，我在项目设置下设置了选项：（C / C ++→调试信息格式）到问题项目的程序数据库（/ Zi）。但是，这并没有阻止该项目的问题。问题来自解决方案中的其他C ++项目之一。

我全部 C ++项目为“程序数据库（/ Zi）”。这解决了问题。

同样，报告问题的项目不是问题项目。尝试将所有项目设置为“程序数据库（/ Zi）”以解决此问题。

我今天遇到了这个问题，但是有点不同。我的解决方案中有一个CUDA DLL项目。可以使用干净的解决方案进行编译，但是可以失败，并且编译器始终将CUDA DLL项目视为未更新。

我尝试了这篇文章的解决方案。

但是在我的解决方案中没有丢失的头文件。然后我找出了我的情况的原因。

我之前已经更改了项目的“中间目录”，尽管它没有引起麻烦。现在，当我将CUDA DLL项目的中间目录更改回$（Configuration）\时，一切再次正常。

我猜在CUDA Build Customization和非默认中间目录之间存在一些小问题。

我遇到了类似的问题，并按照上述说明（已接受的答案）找到了丢失的文件，但并非没有挠头。这是我所做的总结。准确地说，这些不是丢失的文件，因为项目不需要构建（至少在我的情况下），但是它们是对磁盘上不存在的文件的引用，这些文件并不是真正需要的。

这是我的故事：

1. 在Windows 7下，该文件位于%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%。有两个类似的文件devenv.exe.config.config和devenv.exe.config。您想稍后更改。

2. 在Windows 7下，您无权编辑位于程序文件中的该文件。只需将其复制到其他地方（桌面）即可更改它，然后再将其复制回程序文件位置。

3. 我试图弄清楚如何将DebugView连接到IDE以查看丢失的文件。好吧，您无需执行任何操作。只需运行它，它将捕获所有消息。确保Capture Events在Capture菜单中选择了菜单选项，默认情况下应选择该菜单选项。

4. DebugView不会一次显示所有丢失的文件（至少不是我一次）！您将运行DebugView，然后在Visual Studio 2010中运行该项目。它将提示project out of date消息，选择“ 是”进行构建，并且DebugView将显示第一个丢失或导致重建的文件。在记事本中打开项目文件（不是解决方案文件），然后搜索该文件并将其删除。最好关闭您的项目，然后在执行此删除操作时再次将其重新打开。重复此过程，直到DebugView不再显示任何丢失的文件。

5. 通过DebugView工具栏按钮或“ 编辑” →“ 过滤器/突出显示”选项将消息过滤器设置为不最新是很有帮助的。这样，它显示的唯一消息就是其中包含“不最新”字符串的消息。

我有很多文件都是不必要的参考，按照上述步骤将它们全部删除，可以解决此问题。

一次查找所有丢失文件的第二种方法

还有另一种方法可以一次查找所有文件，但是它涉及（a）源代码控制和（b）将其与Visual Studio 2010集成。使用Visual Studio 2010，将项目添加到源代码中的所需位置或虚拟位置控制。它将尝试添加所有文件，包括那些在磁盘上也不存在但在项目文件中引用的文件。转到Perforce之类的源代码控制软件，它将以不同的配色方案标记磁盘上不存在的这些文件。Perforce向他们显示黑色锁。这些是您缺少的参考。现在，您有了所有这些文件的列表，并且可以使用记事本从项目文件中删除所有这些文件，并且您的项目将不会抱怨过时。

对我而言，项目内部的“ Header Files”上不存在头文件。删除此条目（右键单击>从项目中排除）后，第一次重新编译，然后直接编译

==========构建：0成功，0失败，最新5，跳过0 ==========

并没有尝试进行未经修改的重建。我认为这是由VS2010实现的“构建前检查”（不确定是否记录在案），它会触发“ AlwaysCreate”标志。

如果您使用的是命令行MSBuild命令（而不是Visual Studio IDE），例如，如果您定位到AppVeyor或只喜欢命令行，则可以将此选项添加到MSBuild命令行中：

/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8

如此处所述（警告：通常的MSDN详细程度）。构建完成后，will be compiled在构建期间创建的日志文件中搜索字符串MyLog.log。

我正在将Visual Studio 2013 Professional与Update 4配合使用，但没有找到其他建议的解决方案，但是，我确实设法解决了Team项目的问题。

这是导致问题的原因-

• 创建一个新的类对象（Project-> Add Class）
• 通过解决方案资源管理器重命名该文件，并在询问是否要自动重命名所有引用以使其匹配时单击“是”

这是我为解决问题所做的工作-

• 转到团队资源管理器主页
• 单击源代码管理资源管理器
• 钻入所有类/项目文件所在的文件夹
• 在列表中找到原始文件名，然后通过右键单击将其删除
• 建立

如果是这种情况，那么只需确保删除的是幻象文件，而不是要保留在项目中的实际文件即可。

我遇到了这个问题，发现了这一点：

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'.  

您的项目可能仍在构建，但是在找到该文件之前可能会继续过时。

解：

包含afxres.h而不是resource.h在项目的.rc文件中。

项目的.rc文件包含“ #include resource.h”。由于资源编译器不遵守预处理程序#ifdef块，因此它将撕裂并尝试查找应忽略的包含文件。Windows.h包含许多此类块。包括afxres.h则修复了PRJ0041警告，并消除了“项目已过期”错误对话框。

就我而言，其中一个项目包含多个IDL文件。MIDL编译器为每个文件都生成一个名为“ dlldata.c”的DLL数据文件，而与IDL文件名无关。这导致Visual Studio在每次构建时都编译IDL文件，即使不更改任何IDL文件也是如此。

解决方法是为每个IDL文件配置一个唯一的输出文件（即使省略/ dlldata开关，MIDL编译器始终会生成这样的文件）：

• 右键单击IDL文件
• 选择 属性-MIDL-输出
• 为“ DllData文件”属性输入唯一的文件名

我花了很多时间在上面扯头发。构建输出不一致。从一个版本到下一个连续版本，由于不同的原因，不同的项目将是“不最新的”。我最终发现罪魁祸首是DropBox（3.0.4）。我将源文件夹从... \ DropBox连接到我的项目文件夹（不确定是否是这个原因），但是DropBox 在构建过程中以某种方式“接触”了文件。暂停同步，所有内容始终保持最新状态。

有很多潜在原因，并且-如前所述-您首先需要通过将MSBuild详细程度设置为“诊断”来诊断它们。大多数情况下，陈述的原因是不言而喻的，您可以立即采取行动，但有时MSBuild会错误地声称某些文件已修改且需要复制。

如果是这种情况，则需要禁用NTFS隧道或将输出文件夹复制到新位置。 用更多的话在这里。

这发生在我身上多次，然后消失了，直到我弄清楚为什么。以我为例：

双启动设置中的系统时间错误！

原来，我与Ubuntu的双重引导是根本原因！我一直懒得修补Ubuntu，以免弄乱我的硬件时钟。当我登录Ubuntu时，时间向前跳了5个小时。

运气不好，我用错误的系统时间构建了一次项目，然后更正了时间。结果，所有的构建文件都有错误的时间戳，VS会认为它们都已过时并且会重新构建项目。

大多数构建系统使用数据时间戳来确定何时应该进行重建-根据依赖项的上次修改时间检查任何输出文件的日期/时间戳-如果任何依赖项较新，则将重建目标。

如果任何依赖项以某种方式获得了无效的数据时间戳，都会导致问题，因为任何构建输出的时间戳都很难超过将来可能创建的文件的时间戳：P

对我而言，问题出在WPF项目中，其中某些文件的“构建操作”属性设置为“资源”，而“复制到输出目录”属性设置为“如果更新则复制”。解决方案似乎是将“复制到输出目录”属性更改为“不复制”。

msbuild知道不将“资源”文件复制到输出中-但如果文件不在文件中，仍会触发生成。也许可以认为是一个错误？

此处的答案非常有用，它暗示了如何使msbuild散布其为何继续构建一切的原因！

如果更改项目的“调试命令”参数，这也会触发需要重建项目的消息。即使目标本身不受Debugging参数的影响，项目属性也已更改。如果您确实进行了重建，则该消息应消失。

我在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项目需要完整构建，即使在完全清理然后重新构建解决方案之后也是如此。

我通过确保pdbC / C ++和链接器的输出文件与其他工作项目使用的位置匹配来解决此问题。我还打开了RTTI。

在Visual Studio 2015 SP3上还有另一个，但是几年前我在Visual Studio 2013上遇到了类似的问题。

我的问题是，以某种方式将错误的cpp文件用于预编译头（因此，我有两个cpp文件创建了预编译头）。现在，为什么在没有我的要求的情况下，Visual Studio为什么在错误的cpp上将标志更改为“创建预编译的标头”，我却一无所知，但这确实发生了……也许是某些插件之类的东西？？？

无论如何，错误的cpp文件包括在每个版本中都会更改的version.h文件。因此，Visual Studio将重建所有标头，并因此重建整个项目。

好了，现在又恢复了正常行为。

我有一个VC ++项目，该项目始终会编译所有文件，并且以前（由其他人）已从VS2005升级到VS2010。我发现项目中除StdAfx.cpp之外的所有cpp文件都设置为创建（/ Yc）预编译头文件。我对此进行了更改，以便仅将StdAfx.cpp设置为创建预编译的标头，并将其余的设置为使用（/ Yu）预编译的标头，这对我来说解决了这个问题。

我使用的是Visual Studio 2013，只是更新为Windows 10 May 2019更新，因此无论更改如何，每次都必须重做一次编译。尝试将pch重命名为ProjectName而不是TargetName，使用详细的日志和该Python脚本查找丢失的文件，但最后是我的时间未与MS的服务器同步（大约毫秒）。

对我来说解决这个问题的是

• 控制面板中的“调整日期和时间”
• “立即同步”

现在，我的项目无需无故重新编译。

我认为您放置了一些换行符或其他空格。将其卸下，然后再次按F5。

无论如何，始终会重新编译.NET项目。这部分是为了使IDE保持最新（例如IntelliSense）。我记得几年前在一个Microsoft论坛上问过这个问题，这就是我得到的答案。