Visual Studio 2010总是认为项目已经过时，但没有任何改变

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

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

即使在F5被打开之前已经被编译和链接了，消息框“The project is outd date，you want to build it？” 出现。 这是非常烦人的，因为DLL文件是非常低的层次，并迫使解决scheme的几乎所有项目重build。

我的pdb设置被设置为默认值（ 这个问题的build议解决scheme ）。

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

任何其他的想法，为什么Visual Studio 2010的行为呢？

Answer 1

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

要find丢失的文件 ，请使用Enable C ++项目系统日志logging中的信息来启用Visual Studio中的debugging日志logging，让它告诉你什么导致重build：

1. 打开devenv.exe.config文件（位于%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\或%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ ）。 对于Express版本，configuration文件名为V*Express.exe.config 。

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

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

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

6. searchdebugging日志中的任何forms的行：

   devenv.exe信息：0：项目“Bla \ Bla \ Dummy.vcxproj”不是最新的，因为构buildinput“Bla \ Bla \ SomeFile.h”丢失。

   （我只是按Ctrl + F和searchnot up to date ）这些将是引起项目永远“过时”的引用。

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

注意：如果使用2012或更高版本，则片段应该是：

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

Answer 2

在Visual Studio 2012中，我能够比接受的解决scheme更容易地实现相同的结果。

我在菜单工具 → 选项 → 项目和解决scheme → 生成和运行 →MSBuild项目生成输出详细“从最小到诊断改变了选项。

然后在构build输出中，我通过search“不是最新”来find相同的行：

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

Answer 3

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

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

Answer 4

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

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

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

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

一个有效的问题是：如果Visual Studio不知道包含文件的位置，甚至可以构build它们？

我们认为.vcproj文件有一些相关path，它在Visual Studio GUI中没有显示的地方，这就解释了为什么项目实际上会生成，即使包含的树视图是不正确的。

Answer 5

被接受的答案帮助我find了解决这个问题的正确方法，因为我不得不开始合作。 但是，我不得不面对很多不好的头文件。 使用详细的debugging输出，删除一个导致IDE冻结30秒，同时输出debugging信息，这使得进程非常缓慢。

我感到不耐烦，写了一个快速肮脏的Python脚本来为我检查（Visual Studio 2010）项目文件，并一次性输出所有丢失的文件以及它们所在的filter。您可以将其作为要点在这里： https ： //gist.github.com/antiuniverse/3825678 （或支持相对path的这个叉 ）

例：

 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

我已经从解决scheme（和磁盘）删除了一个cpp和一些头文件，但仍然有问题。

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

要么手动编辑这个.tlog文件，要么清理你的项目并重build。

Answer 7

我有一个类似的问题，但在我的情况下，没有文件丢失，在如何定义pdb输出文件时出错：我忘了后缀.pdb（我发现与debugging日志logging技巧）。

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

 <ProgramDataBaseFileName>MyName</ProgramDataBaseFileName> 

至

 <ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName> 

Answer 8

我在VS2013（更新5）有这个问题，可以有两个原因，你可以通过在“工具” – >“项目和解决scheme” – >“生成并运行”下启用“详细” 。

1. "Forcing recompile of all source files due to missing PDB "..."
   当您在您的编译器选项中禁用debugging信息输出（在项目设置：“C / C ++” – >“debugging信息格式”到“无”和“链接器” – >“生成debugging信息”为“否” 。 如果您在默认情况下（即“$（IntDir）vc $（PlatformToolsetVersion）.pdb”）离开了“C / C ++” – >“程序数据库文件名”，VS将无法find该文件（ https ：//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-命令行自上一次构build ），似乎在新版本（但不是VS2013）中修复。 我知道没有解决办法，但如果你这样做，一定要把它张贴在这里。

Answer 9

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

更改configuration：菜单工具 → 选项 → 项目和解决scheme → VC ++项目设置 → 解决scheme资源pipe理器模式 显示所有文件 。

然后，您可以在“解决scheme资源pipe理器

find标有黄色图标的文件，并将其从项目中删除。

没关系。

Answer 10

对我来说，这是在项目中的“头文件”存在一个不存在的头文件。 删除此条目后（右键单击>从项目排除）首次重新编译，然后直接

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

没有修改的尝试没有完成。 我认为是由VS2010实现的一个check-before-build（不知道是否logging，可能是）触发“AlwaysCreate”标志。

Answer 11

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

Answer 12

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

我试过这个post的解决scheme。

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

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

我想在CUDA构build自定义和非默认中间目录之间存在一些小问题。

Answer 13

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

这是我的故事：

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 Events菜单选项被选中，默认情况下应该被选中。

4. DebugView不会一次显示所有丢失的文件（至less它不适合我）！ 您将运行DebugView，并在Visual Studio 2010中运行该项目。它将提示project out of date消息，select“ 是”进行构build，DebugView将显示缺less的第一个文件或导致重build。 在记事本中打开项目文件（不是解决scheme文件）并search该文件并将其删除。 你最好closures你的项目，并重新打开，同时做这个删除。 重复此过程，直到DebugView不再显示任何文件丢失。

5. 将消息filter设置为从DebugView工具栏button或编辑 → filter/加亮选项不是最新版本是有帮助的。 这样，它显示的唯一的消息就是那个'不是最新的'string。

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

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

还有第二种方法来一次find这些文件，但它涉及（a）源代码pipe理和（b）与Visual Studio 2010的集成。 使用Visual Studio 2010 ，将项目添加到所需位置或源中的虚拟位置控制。 它会尝试添加所有的文件，包括那些在磁盘上不存在但在项目文件中被引用的文件。 转到您的源代码pipe理软件，如Perforce ，它应该标记这些不存在的磁盘上的文件在不同的配色scheme。 Perforce向他们展示了一个黑色的锁。 这些是你遗漏的参考资料。 现在你有一个列表，你可以使用记事本从你的项目文件中删除所有的项目，你的项目不会抱怨过期 。

Answer 14

我有这个问题，发现这一点：

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中，我的一个项目总是声称是过时的，即使没有任何改变，并且在最后的构build中没有报告错误。

打开相应项目的BuildLog.htm文件显示这些文件的PRJ0041错误的列表，其中没有任何出现在我的系统任何地方：winwlm.h macwin32.h rpcerr.h macname1.h

每个错误看起来像这样：

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'. 

您的项目可能仍然会生成，但可能会继续显示过时，直到find此文件。

解：

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

该项目的.rc文件包含“#include resource.h”。 由于资源编译器不支持预处理程序#ifdef块，它将会穿透并尝试find它应该忽略的包含文件。 Windows.h包含许多这样的块。 包括afxres.h，而不是固定PRJ0041警告，并消除“项目是过时的”错误对话框。

Answer 15

在我的情况下，其中一个项目包含多个IDL文件。 MIDL编译器生成一个名为“dlldata.c”的DLL数据文件，不pipeIDL文件名是什么。 这导致Visual Studio在每个版本上编译IDL文件，即使不更改任何IDL文件。

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

• 用鼠标右键单击IDL文件
• select属性 – MIDL – 输出
• 为DllData文件属性input一个唯一的文件名

Answer 16

我花了好几个小时花了我的头发。 构build输出不一致; 不同的项目从一个构build到下一个连续构build的不同的原因将是“不是最新的”。 我最终发现，罪魁祸首是DropBox （3.0.4）。 我将源文件夹从… \ DropBox连接到我的项目文件夹（不确定是否是这个原因），但DropBox莫名其妙地在构build过程中 “触及”文件。 暂停同步，一切都始终保持最新。

Answer 17

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

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

Answer 18

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

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

正如这里所logging的（警告：通常的MSDN详细程度）。 当构build完成时，searchstringwill be compiled在构build期间创build的日志文件MyLog.log 。

Answer 19

我用更新4使用Visual Studio 2013专业版，但没有find任何其他build议的解决scheme，但是，我设法解决了我的团队项目的问题。

这是我所做的导致这个问题 –

• 创build一个新的类对象（项目 – >添加类）
• 通过解决scheme资源pipe理器重命名文件，当被问及是否想要自动重命名所有引用匹配时，单击yes

这是我做了什么来解决这个问题 –

• 转到团队资源pipe理器主页
• 点击源代码pipe理资源
• 钻入所有类/项目文件所在的文件夹
• 在列表中find原始文件名并通过右键单击将其删除
• build立

如果是这种情况，那么请确保您删除幻影文件，而不是您想保留在项目中的幻影文件。

Answer 20

Visual Studio 2013 – “由于缺lessPDB而强制重新编译所有源文件”。 我打开了详细的构build输出以find问题：我在“工具”→“项目和解决scheme”→“构build和运行”下启用了“详细”构build输出。

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

我将所有 C ++项目设置为“程序数据库（/ Zi）”。 这解决了这个问题。

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

Answer 21

如果您更改项目的debugging命令参数，这也会触发项目需要重build的消息。 即使目标本身不受debugging参数的影响，项目属性也已更改。 如果你重build，消息应该消失。

Answer 22

这发生在我身上多次，然后走了，才找出原因。 在我的情况是这样的：

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

原来，我与Ubuntu的双重启动是根本原因！ 我一直懒得修理Ubuntu来阻止我的硬件时钟。 当我login到Ubuntu时，时间跳了5个小时。

由于运气不好，我一次性build造了这个项目，系统时间错了，然后纠正了时间。 因此，所有的构build文件都有错误的时间戳，VS会认为它们都是过时的，并会重build项目。

Answer 23

大多数构build系统使用数据时间戳来确定何时应该进行重build – 任何输出文件的date/时间戳都会根据依赖关系的最后修改时间进行检查 – 如果任何依赖关系更新，则重build目标。

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

Answer 24

我有一个与Visual Studio 2005类似的问题，我的解决scheme包含五个项目在以下依赖项（首先build立在顶部）：

 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项目需要完整的构build，即使完全清理然后重build解决scheme。

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

Answer 25

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

我的问题是，某种错误的cpp文件被用于预编译头文件（所以我有两个cpp文件创build了预编译头文件）。 现在为什么Visual Studio将错误的cpp上的标志更改为“创build预编译头文件”而没有我的请求我不知道，但它确实发生了……也许有一些插件或东西？

无论如何，错误的cpp文件包含了version.h文件，在每个版本上都有所改变。 所以Visual Studio重build所有的头文件，因为整个项目。

那么，现在又回到了正常的行为。

Answer 26

.NET项目总是重新编译，无论。 其中的一部分是让IDE保持最新（如IntelliSense）。 我记得几年前在微软的论坛上提过这个问题，这就是我给出的答案。