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

Posted 2023-02-22

【中文标题】Visual Studio 2010 总是认为项目已过时，但没有任何改变

【英文标题】：Visual Studio 2010 always thinks project is out of date, but nothing has changed

【发布时间】：2010-05-04 05:06:06

【问题描述】：

我遇到了与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 的行为方式有何其他想法？

【问题讨论】：

参考***.com/questions/31547931/…

参考***.com/questions/31547931/…

【参考方案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 或更高版本，则 sn-p 应为：

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

【讨论】：

> 打开 DbgView 并确保它正在捕获调试输出。如何确保开始捕获？我对重建项目有同样的问题。但是 DebugView 中没有任何信息。我在 DebugView 的“Capture”菜单中启用了前 5 个选项。 （并感谢回答中的良好链接！）

这帮助我们弄清楚了；但是，我们还必须在最后一个 .H 引用消失之前删除我们的中间构建目录——可能是为了刷新 StdAfx.obj？无论如何，删除所有中间构建文件夹并清理项目文件后，我们也可以开始了。

谢谢 - 现在为什么不在常规输出窗口中？

如果您使用的是 VS2012，则粘贴到配置文件中的 sn-p 略有不同。这是从原始文章链接的，但以防万一：Enable C++ and javascript project system tracing VS2012

仅供参考，这在 VS2013 中似乎不再起作用 - 编辑配置文件后，它不会在 DebugView 中生成任何感兴趣的内容。

【参考方案2】：

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

我更改了菜单中的选项 Tools → Options → Projects and Solutions → Build and Run → * MSBuild 项目构建输出详细程度“从 Minimal 到 Diagnostic。

然后在构建输出中，我通过搜索“not up to date”找到了相同的行：

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

【讨论】：

这也适用于 VS2013，其中配置文件调整似乎不再起作用。

这对我来说效果很好。原来我有一个循环引用（project1 -> project2，project2 -> project1.dll），这导致每次都构建大部分解决方案。它甚至没有被使用。

使用 C#，我找不到任何带有“不是最新”的东西，神奇的词似乎是“比更新”

1>Project not up to date because build input 'C:\...\ReadMe.txt' is missing. :O !!?!

在 VS2013 中，您可能还必须在诊断模式下搜索 was modified at，因为我没有 not up to date 输出。

【参考方案3】：

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

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

【讨论】：

不，我没有磁盘上不存在的任何头文件。但是你是如何找到原因的呢？您是如何发现文件丢失的？也许我可以通过像你一样的方式来检查我的问题。

当我遇到这种情况时，有一个不同的解决方案。可能非常晦涩难懂，但我是从一台计算机编译项目，然后是另一台计算机，发现我不小心将时间设置为在一台计算机上设置为上午，而在另一台计算机上设置为下午。巨大的时间差异导致其中一台计算机要么总是编译所有内容，要么即使我修改了源文件也从不编译任何内容。

这对我有用，尽管头文件存在。使用下面的答案启用日志记录，它认为缺少头文件。我删除了它的依赖项，重新添加了它，最小的重建再次工作！

时钟偏差会导致大多数构建系统崩溃

【参考方案4】：

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

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

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

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

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

我们认为 .vcproj 文件在 Visual Studio GUI 中未显示的某处有问题文件的相对路径，这解释了为什么即使包含的树形视图不正确，项目仍会实际构建.

【讨论】：

VC 可以构建的原因是因为它们是头文件——而头文件实际上并没有被编译。如果 .C/.CPP 文件实际使用了任何头文件，那么只有这样，构建才会失败。所以依赖检查器（它查找头文件）将项目标记为需要重建，但实际的编译器（它只是忽略头文件列表）可以成功。

难以置信...如果您对 text 文件有过时的引用，也会发生这种情况（即使它确实存在，它也不是构建的一部分！！）在您的 .vcxproj 文件中。我使用向导生成了一个项目，其中包含一个 ReadMe.txt 文件，我从磁盘上删除了该文件，但忘记从 vcxproj 中删除。

我找不到任何我无法打开的文件（除了一个，但它在硬盘驱动器上。它说类似那种文件无法在 Visual Studio 上打开2010 Express SKU 或类似的东西。

什么是“包含文件视图”，您如何获得它？

Include File View 可能是解决方案资源管理器中的 Include Files 部分。

【参考方案5】：

接受的答案帮助我找到了解决这个问题的正确途径，我不得不开始处理这个搞砸的项目。但是，我不得不处理大量错误的包含标头。对于详细的调试输出，删除一个会导致 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 + ")")

【讨论】：

修改了您的代码以支持相对路径。随时更新您的要点并删除指向我的 fork 的链接！

这对我很有用！多么节省时间！谢谢！我在诊断输出中没有任何内容告诉我出了什么问题，但您的实用程序向我展示了！

另一个 fork 枚举一个目录并在每个找到的 vcxproj gist.github.com/paulsapps/4992d2d460f4ef44538d62c9e875ca78

上调用它

【参考方案6】：

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

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

要么手动编辑此 .tlog 文件，要么清理您的项目并重新构建。

【讨论】：

这是给我的！我在修复丢失的包含文件后花了几个小时，仍然过时，日志显示对丢失的内容的抓取没有定论。需要摆脱那些 TLOG 文件！谢谢！

【参考方案7】：

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

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

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

到

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

【参考方案8】：

我在 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）。我知道没有解决方法，但如果你这样做了，请务必在此处发布。

【讨论】：

这就是我的问题。我的所有“不是最新的”消息都没有，我们花了很长时间才找到它。也删除它或将其设置为 $(IntDir)$(ProjectName).pdb 为我们工作（确保为调试和发布配置更改它）

【参考方案9】：

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

【讨论】：

+1 这也适用于我，在 Visual Studio 2013 上。具体来说，当我将其 返回 切换为 None 时，它​​也能正常工作。

【参考方案10】：

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

更改配置：菜单 Tools → Options → Projects and Solutions → VC++ Project Settings → 解决方案资源管理器模式到显示所有文件。

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

找到标有黄色图标的文件并将它们从项目中删除。

没关系。

【参考方案11】：

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

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

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

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

【讨论】：

VS2015对于详细构建输出的设置是一样的

【参考方案12】：

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

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

但我的解决方案中没有缺少头文件。然后我发现了我的情况的原因。

我之前更改过项目的中间目录，虽然没有造成麻烦。 现在，当我将 CUDA DLL 项目的中间目录改回 $(Configuration)\ 时，一切都恢复正常了。

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

【讨论】：

使用 VS2013 (C#)，我尝试设置 IntermediateOutputPath。如果这指向不同驱动器上的文件夹，那么解决方案，增量构建将停止工作 - MSBuild 抱怨某些源文件总是与某些中间文件（通常是 PDB）过时。见my blog post。

【参考方案13】：

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

这是我的故事：

在 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 向他们展示了他们身上的黑色锁。这些是您缺少的参考资料。现在您有了一个全部列表，您可以使用记事本从项目文件中删除所有这些，并且您的项目不会抱怨过时。

【参考方案14】：

对我来说，项目内部的“头文件”上存在一个不存在的头文件。去掉这个条目后（右键>Exclude from Project）第一次重新编译，然后直接

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

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

【参考方案15】：

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

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

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

【讨论】：

/verbosity:detailed 也会提供相同的信息，但不会那么冗长。然后你可以搜索“将被编译为”。

您还应该搜索“需要源代码编译”，这也会找到链接

【参考方案16】：

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

这是我造成问题的原因 -

创建了一个新的类对象（项目 -> 添加类） 通过解决方案资源管理器重命名文件并在询问我是否要自动重命名所有引用以匹配时单击“是”

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

转到团队资源管理器主页 单击源代码管理资源管理器 钻入所有类/项目文件所在的文件夹 在列表中找到ORIGINAL文件名并右键删除 构建

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

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

【参考方案18】：

在我的例子中，其中一个项目包含多个 IDL 文件。 MIDL 编译器为它们中的每一个生成一个名为“dlldata.c”的 DLL 数据文件，而不管 IDL 文件名如何。这导致 Visual Studio 在每次构建时都编译 IDL 文件，即使没有更改任何 IDL 文件。

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

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

【参考方案19】：

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

【参考方案20】：

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

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

【参考方案21】：

这在我身上发生了很多次，然后在我弄清楚原因之前就消失了。在我的情况下是：

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

事实证明，我的 Ubuntu 双重启动是根本原因！我一直懒得修复 Ubuntu 以停止弄乱我的硬件时钟。当我登录 Ubuntu 时，时间向前跳了 5 个小时。

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

【参考方案22】：

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

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

【讨论】：

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

在 VS6 或 VS2005 中，当右键单击一个项目时会出现一个奇怪的小属性对话框，该对话框具有显示项目中每个文件的依赖项和输出的选项卡。我不知道如何在VS2008（或VS2010）中获得等效报告

【参考方案23】：

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

msbuild 知道不将“资源”文件复制到输出 - 但如果它们不存在，仍会触发构建。也许这可以被认为是一个错误？

这里的答案非常有帮助，提示如何让 msbuild 透露为什么它会继续构建所有内容！

【参考方案24】：

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

【参考方案25】：

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

【参考方案26】：

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

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

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

嗯，现在又恢复正常了。

【参考方案27】：

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

【参考方案28】：

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

为我解决这个问题的是

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

现在我的项目不需要无缘无故地重新编译了。

【参考方案29】：

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

【参考方案30】：

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

【讨论】：

在 VS2008 中，项目并非每次都重建。这很烦人，因为 dll 的层次非常低，并且强制我几乎所有的 dll 重新构建。迁移时出了点问题，我不知道是什么。

2008、2010、2012 和 2013 不会每次都重建 .NET 项目

正在进行后台编译（请记住这个答案已有 10 年历史）以保持智能感知功能。我