Question

我遇到了与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会有这样的行为？

Answer 1

仅适用于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>

重新启动Visual Studio
打开DbgView并确保它捕获调试输出
尝试调试（在Visual Studio中点击F5）
在调试日志中搜索表单的任何行：

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>

Answer 2

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

我更改了菜单工具→选项→项目和解决方案→构建和运行→*中的选项MSBuild项目构建输出详细程度“从 Minimal 到 Diagnostic 。

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

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

Answer 3

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

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

Answer 4

我们也遇到了这个问题并找到了如何解决它。

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

这不太正确。该文件确实存在于磁盘上，但.VCPROJ文件正在其他地方引用该文件。

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

一个有效的问题是：如果Visual Studio不知道包含文件的位置，它们如何构建？

我们认为.vcproj文件在Visual Studio GUI中没有显示某个违规文件的相对路径，这说明了即使包含的树视图不正确，项目实际构建的原因也是如此

Answer 5

接受的答案帮助我找到了解决这个问题的正确途径，以解决我必须开始合作的搞砸项目。但是，我不得不处理大量错误的包含标头。使用详细的调试输出，删除一个导致IDE冻结30秒，同时输出调试spew，这使得进程非常缓慢。

我不耐烦了，写了一个快速而肮脏的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 + ")")

Answer 6

我已从解决方案（以及磁盘）中删除了一个cpp和一些头文件但仍有问题。

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

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

Answer 7

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

"Forcing recompile of all source files due to missing PDB "..."
当您在编译器选项中禁用调试信息输出时会发生这种情况（在项目设置：“C / C ++” - ＆gt;“调试信息格式”到“无”和“链接器” - >“生成调试信息”到“否” :)。如果您在默认情况下保留了“C / C ++” - ＆gt;“程序数据库文件名”（即“$（IntDir）vc $（PlatformToolsetVersion）.pdb”），由于错误，VS将无法找到该文件（ https://connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds）。
要修复它，只需将文件名清除为“”（空字段）。
"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）中得到修复。我知道没有解决方法，但如果你这样做，请将其发布在这里。

Answer 8

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

要解决我在vxproj文件中更改的问题，请执行以下行：

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

到

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

Answer 9

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

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

我将所有 C ++项目设置为“Program Database（/ Zi）”。这解决了这个问题。

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

Answer 10

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

Answer 11

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

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

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

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

没关系。

Answer 12

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

这是我的故事：

在Windows 7下，该文件位于%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%。有两个类似的文件devenv.exe.config.config和devenv.exe.config。你想稍后改变。
在Windows 7下，您无权编辑程序文件中的此文件。只需将其复制到其他地方（桌面）进行更改，然后将其复制回程序文件位置。
我试图找出如何将DebugView连接到IDE以查看丢失的文件。好吧，你不需要做任何事情。只需运行它，它将捕获所有消息。确保在Capture Events菜单中选择了Capture菜单选项，默认情况下应该选择该菜单。
DebugView不会一次显示所有丢失的文件（至少它不适合我）！您将运行DebugView，然后在Visual Studio 2010中运行该项目。它将提示project out of date消息，选择是进行构建，DebugView将显示第一个缺少或导致重建的文件。在记事本中打开项目文件（不是解决方案文件）并搜索该文件并将其删除。最好关闭项目并在执行此删除时再次重新打开它。重复此过程，直到DebugView不再显示任何文件丢失。
从DebugView工具栏按钮或编辑→过滤/突出显示将消息过滤器设置为不是最新的是有帮助的em>选项。这样，它显示的唯一消息是其中包含“不是最新”字符串的消息。

我有很多不必要的引用文件，删除它们都解决了上述步骤后的问题。

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

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

Answer 13

我今天遇到了这个问题，但有点不同。我的解决方案中有一个CUDA DLL项目。在一个干净的解决方案中编译是好的，但否则它失败了，编译器总是将CUDA DLL项目视为不是最新的。

我尝试了this post的解决方案。

但我的解决方案中没有丢失的头文件。然后我发现了我的理由。

之前我已经更改了项目的中间目录，虽然它没有造成麻烦。 现在，当我将CUDA DLL项目的中间目录更改回$（配置）\时，一切正常。

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

Answer 14

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

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

并没有做任何未经修改的重建尝试。我认为是VS2010实现的check-before-build（不确定是否记录在案）可以触发“AlwaysCreate”标志。

Answer 15

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

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

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

Answer 16

我正在使用Visual Studio 2013 Professional和Update 4，但没有找到任何其他建议的解决方案，但是，我确实设法解决了我的团队项目的问题。

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

创建了一个新的类对象（Project - ＆gt; Add Class）
通过解决方案资源管理器重命名该文件，并在询问我是否要自动重命名所有引用以匹配

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

转到团队资源管理器主页
单击“源代码管理资源管理器”
深入到所有类/项目文件
在列表中找到ORIGINAL文件名，并通过右键单击
构建

如果您遇到这种情况，那么请确保您正在删除幻像文件，而不是要保留在项目中的实际文件。

Answer 17

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

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警告并消除“项目已过期”错误对话框。

Answer 18

在我的情况下，其中一个项目包含多个IDL文件。 MIDL编译器生成一个名为＆＃39; dlldata.c＆＃39;的DLL数据文件。对于每个人，无论IDL文件名如何。这导致Visual Studio在每次构建时编译IDL文件，即使不更改任何IDL文件也是如此。

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

右键单击IDL文件
选择属性 - MIDL - 输出
输入 DllData文件属性

Answer 19

我花了很多时间把头发撕掉了。构建输出不一致;不同的项目将是＆＃34;不是最新的＆＃34;出于不同的原因，从一个构建到下一个连续构建。我最终发现罪魁祸首是 DropBox （3.0.4）。我将我的源文件夹从... \ DropBox连接到我的项目文件夹（不确定这是否是原因），但DropBox以某种方式＆＃34;触及＆＃34; 构建期间的文件。暂停同步，一切都是最新的。

Answer 20

有很多潜在的原因，并且 - 如上所述 - 您需要首先通过将MSBuild详细程度设置为“Diagnostic”来诊断它们。大多数情况下，陈述的理由是自我解释的，你可以立即采取行动，但偶尔MSBuild会错误地声称某些文件被修改并需要复制。

如果是这种情况，您需要禁用NTFS隧道或将输出文件夹复制到新位置。 Here it is in more words.

Answer 21

对我来说，问题出现在一个WPF项目中，其中一些文件有他们的＆＃39; Build Action＆＃39;属性设置为＆＃39;资源＆＃39;和他们的'复制到输出目录＆＃39;设置为＆＃39;复制如果更新＆＃39;。解决方案似乎是要将“复制到输出目录”更改为＆＃39;财产到＆＃39;不要复制＆＃39;。

msbuild知道不要复制资源＆＃39;文件到输出 - 但如果它们不在那里仍会触发构建。也许这可能被视为一个错误？

这里的答案非常有帮助，暗示了如何让msbuild将豆子放在为什么一直在构建所有内容之上！

Answer 22

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

Answer 23

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

Answer 24

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

为我解决的是

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

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

Answer 25

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

我的问题是，某个错误的cpp文件被用于预编译头文件（所以我有两个cpp文件创建了预编译头文件）。现在为什么Visual Studio将错误的cpp上的标志更改为'创建预编译的标头'而没有我的请求我没有任何线索，但它确实发生了......也许是一些插件或什么???

无论如何，错误的cpp文件包含version.h文件，该文件在每次构建时都会更改。因此，Visual Studio会重建所有标题，因此整个项目都会重建。

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

Answer 26

如果更改项目的Debugging Command参数，这也将触发项目需要重建的消息。即使目标本身不受Debugging参数的影响，项目属性也已更改。如果您确实重建，则消息应该消失。

Answer 27

我在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。

Answer 28

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

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

Answer 29

无论如何，.NET项目总是被重新编译。部分原因是为了使IDE保持最新（例如IntelliSense）。我记得几年前在微软论坛上提出这个问题，这就是我给出的答案。

Visual Studio 2010始终认为项目已过时，但一切都没有改变

29 个答案:

问题：

解决方案：