所以，正如 Headers 所示，我现在有一个VS2010解决方案，里面有大约50个项目 . 如果我对没有引用的“顶级”项目进行更改，那么VS仍会重建所有50个项目 . 我正在运行Visual Studio 2010 Ultimate而没有任何附加组件 . 我正在使用ILMerge将所有项目合并到一个文件中 .
我已经通过检查较低级别dll的时间戳来验证这一点，并且看到它们确实已经重建，即使它们的代码没有被触及 .
我已阅读所有回复和评论：
Visual Studio 2008 keeps rebuilding
Visual studio keeps building everything
Strange VS2010 build glitch occurs in my solution
Reasons for C# projects to rebuild in Visual Studio
但是他们中的大多数只提供卸载项目的建议，以加快构建时间，但没有具体的解决方案 . 我试图弄清楚为什么VS认为这些依赖项目需要在不修复时进行重建 .
我已经打开了'工具>选项>项目和解决方案>构建和运行>仅在运行时构建启动项目和依赖项'但没有任何效果 .
此外，如果我只是重建一个只有8个（in）直接依赖项的“中级”项目，那么即使没有调用ILMerge并且没有修改任何依赖项目，它仍会构建所有8个项目 .
感谢大家提供的任何见解 .
Added
为了测试一些建议，我从头开始创建一个新的WinForms项目 . 然后我在该解决方案中创建了两个新项目 . 我将所有代码和资源（不是项目文件）从我的两个“最低级别”项目复制到两个全新的项目中（我通过将资源管理器中的文件和文件夹放到Visual Studio中的项目中来完成此操作） .
最低的项目，我们称之为 B ，没有引用任何其他项目 . 下一个项目 A 仅引用 B . 因此，一旦我将所需的.NET和外部程序集引用添加到项目中，那么解决方案就会构建 .
然后我获得了我的新WinForm项目参考 A 并完成了一个完整版本 . 所以ref链是：
WinForm - > A - > B
然后我修改了 WinForm 并进行了标准构建（F6） . 和以前一样，Visual Studio重建了所有三个项目 .
在项目 B 中对源文件进行了一些系统的删除后，我发现如果我删除了 Resources.Designer.cs 和 Resources.resx （并注释掉了使用这些资源的 .Properties.Resources 对象的代码），那么 WinForm 的修改将不再重建整个解决方案，只会重建 WinForm .
将 Resources.resx 和 Resources.Designer.cs 添加回项目 B （但保留引用的代码以便不使用任何资源）将重新引入完整的构建行为 .
要查看我的资源文件是否已损坏，我再次删除它们，然后创建一个新文件（通过Project Properties - > Resources）并重新添加与以前相同的资源，这是一个单独的Excel文件 . 使用此设置，仍将进行完全重建 .
然后我删除了单个资源，但将资源文件保留在项目 B 中 . 即使没有添加资源，但资源文件仍在项目中，也会发生完全（不需要的）重建 .
看起来只是将资源文件添加到（.NET 3.5）项目中将导致Visual Studio 2010始终重建该项目 . 这是一个错误或预期/预期的行为？
再次感谢所有人！
14 回答
打开工具 - 选项，选择项目和解决方案 - 在树中构建和运行，然后将“MSBuild项目构建输出详细程度”设置为Diagnostic . 这将输出 Build 项目的原因，即
要么
在这种情况下，修复是仅在较新时复制some.xml .
构建前事件和后期构建事件也可以触发构建 .
虽然我不认为这是一个修复，但这是一个解决方案，适用于我的情况......
我最初有50个项目中有5个项目包含
Resources部分 . 这些项目将永远重建，因此他们所依赖的任何东西也将被重建 . 这5个项目中的一个是一个"base"级别的库，其他项目中有48个被引用，因此每次重建项目的96％即使它不需要它也是如此 .我的解决方法是使用依赖注入，接口和一个专门的"Resources"项目 . 我没有让这5个项目引用自己的
Resources对象，而是在每个项目中创建了一个可提供所需资源的接口 . 然后，需要这些资源的类将要求在构造函数（构造函数注入）中创建它们时传入接口 .然后，我创建了一个单独的“资源”项目，其中有一个像normal一样的实际Resources部分 . 该项目仅包含资源本身，以及通过接口提供这些资源所需的每个接口的类 . 该项目将引用具有资源依赖性的所有其他项目，并实现项目所需的接口 .
最后，在我的“顶级”项目中没有引用任何内容（以及exe实际构建的位置和我的组合根目录）我参考了“资源”项目，连接了DI，然后我们去了 .
这意味着每次只重建两个项目（“资源”和“顶层”），如果我进行部分构建（Shift-F6），那么它们根本不会重建 .
同样，这不是一个很好的工作，但是每次构建需要大约3分钟时就会构建48个项目，所以我每天都会因为不必要的重建而损失30到90分钟 . 重构需要一段时间，但我认为这是一项很好的投资 .
这是一个简化的图表 . 请注意，为了减少混乱，未显示从
Main.exe到Proj1和Proj2的依赖关系 .通过这种设计，我可以在不触发完全重建的情况下进行
Proj1或Proj2的构建，因为它们对Resources部分没有任何依赖性 . 只有Main知道Resources实现 .当项目具有实际不存在的文件时，会发生这种情况 .
该项目可以't determine if the file was changed (because it'不存在）所以它重建 .
只需查看项目中的所有文件，然后搜索附近没有可扩展箭头的文件 .
我在VS 2015中遇到了同样的问题 .
对我来说诀窍是：
一个项目在其他项目箱中引用了自己的副本（魔术，是的） . 切换到诊断构建输出（在构建选项中），然后尝试从项目层次结构的顶部逐个构建项目时，可以找到这种东西 - 如果您看到即使没有任何更改也会重建项目，那么请查看它引用 .
我已将所有项目中的所有"copy always"文件更改为"copy if newer" . 基本上，在所有.csproj文件中将
<CopyToOutputDirectory>Always</CopyToOutputDirectory>替换为<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>然后我按照this文章中的描述使用此powershell脚本禁用了NTFS隧道：
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "MaximumTunnelEntries" -Value 0 -PropertyType "DWord"之后我需要重建，现在似乎有效 .
在我的情况下，罪魁祸首是“复制本地”设置引用的dll设置为true和“复制到输出目录”设置文件设置为复制始终 .
MSBuild团队正在收集有关调查构建增量问题的文档：https://github.com/Microsoft/MSBuild/wiki/Rebuilding%20when%20nothing%20changed
我终于找到了另一个罪魁祸首，我通过增加构建日志详细程度很难找到 .
在某些情况下，MSBuild在输出文件夹中查找 vc120.pdb ，如果此文件不存在，它将重建整个项目 . 即使您已禁用调试符号生成，也会发生这种情况 .
此处的解决方法是启用调试符号并生成此文件，然后再次禁用该设置而不删除PDB文件 .
以下是VS2010 always rebuilds solution?的回答
根据您的观察，听起来您有一些项目以不明显的方式表达对其他项目的依赖性 . 孤立的依赖项可能保留在项目文件中，而不会在UI中显现 . 在文本编辑器中打开后，您是否查看了行为不端的项目文件？检查解决方案构建依赖关系？
如果您无法发现任何内容，请尝试从头开始重新创建一个项目，以查看新项目是否存在同样的问题 . 如果干净的项目正确构建，您将知道您在某处表达了不需要的依赖项 . 据我所知，这些必须在项目文件或解决方案文件中，除非你有makefile或其他不寻常的构建步骤 .
我和你有同样的问题 . 我发现了它来自一些已删除的文件 . 当我从项目中删除文件时，问题就消失了 . 问候 .
对于此类构建问题，将MSBuild输出详细程度设置为“诊断”确实是必要的第一步 . 大多数情况下，重新构建的原因足以采取行动，但偶尔MSBuild会错误地声称某些文件已被修改并需要复制 .
如果是这种情况，则需要禁用NTFS隧道或将输出文件夹复制到新位置 . Here it is in more words.
经常发生的另一个问题是，解决方案中的某些项目具有未来的修改标记 . 如果您将时钟向前设置，然后将时钟设置为正确的时间，则会发生这种情况 . 我在安装Linux时遇到了这种情况 .
在这种情况下，您可以使用git bash递归触摸所有文件（是的，在Windows中）：
从Visual Studio 2015升级到2017时，我遇到了Visual Studio重建项目的问题，我添加了这个答案，以便为那些可能遇到类似问题的人带来好处，因为它似乎没有记录在任何地方 .
在我的例子中，问题是解决方案中的所有项目都具有相同的中间输出路径（obj） . GeneratedInternalTypeHelper.cs文件由包含XAML的所有项目生成 . 到Visual Studio 2015，构建过程显然没有检查此文件的文件日期，因此没有出现问题 . 使用VS2017，将检查此文件的文件日期，并且因为构建过程中的后续项目将覆盖它（具有相同的内容），之前的项目将重新构建，重新触发后续构建，无限制 .
在这种情况下，解决方案是确保所有项目都有不同的中间输出目录，这将使问题消失 .
我遇到了同样的问题，结果发现它与一些项目有关，这些项目在自己的输出目录中有一个复制本地引用的dll .
找到这个的关键是为构建输出设置诊断输出，但也知道在日志中要查找的内容 . 正在寻找：' not up to date '是关键 .