对于我使用 Visual C++ 进行的大部分开发工作，我使用的是部分构建，例如按 F7 并仅重新构建更改的 C++ 文件和它们的依赖关系，然后是增量链接。在将版本传递给测试之前，我会采取预防措施进行完全重建，这在我当前的项目中大约需要 45 分钟。我看到很多帖子和文章都在提倡这一行动，但想知道这是否必要，如果有，为什么？它是否会影响交付的 EXE 或相关的 PDB（我们也在测试中使用）？从测试的角度来看，该软件的功能会有所不同吗？
对于发布版本，我使用的是 VS2005、增量编译和链接、预编译头文件。
部分构建系统通过根据构建结果检查源文件的文件日期来工作。因此，如果您从源代码管理中恢复较早的文件，它可能会中断。较早的文件将具有早于构建产品的修改日期，因此不会重新构建产品。为了防止这些错误，如果它是最终构建，您应该进行完整构建。但是，在您进行开发时，增量构建当然要高效得多。
编辑：当然，进行完全重建也可以保护您免受增量构建系统中可能存在的错误的影响。
基本问题是编译依赖于环境（命令行标志、可用库，可能还有一些黑魔法），因此只有在相同条件下执行两次编译才会产生相同的结果。对于测试和部署，您希望确保环境尽可能受控，并且不会因为奇怪的代码而出现古怪的行为。一个很好的例子是如果你更新一个系统库，然后重新编译一半的文件——一半仍在尝试使用旧代码，一半没有。在一个完美的世界中，这要么会立即出错，要么不会导致任何问题，但遗憾的是，有时这些都不会发生。因此，进行完整的重新编译避免了许多与交错构建过程相关的问题。
是不是每个人都遇到过这种使用模式？我得到了奇怪的构建错误，甚至在调查之前我进行了完全重建，问题就消失了。
在我看来，这本身就足以成为在发布之前进行全面重建的充分理由。
我认为，您是否愿意将完成时没有问题的增量构建转用于测试，这是一个品味问题。
我肯定会推荐它。我曾多次在大型 Visual C++ 解决方案中看到依赖检查器无法检测到对更改代码的某些依赖。当此更改针对影响对象大小的头文件时，可能会开始发生非常奇怪的事情。我确信依赖检查器在 VS 2008 中变得更好，但我仍然不相信它会用于发布版本。
不发布增量链接二进制文件的最大原因是某些优化被禁用。链接器将在函数之间留下填充（以便在下一个增量链接上更容易替换它们）。这给二进制文件增加了一些膨胀。也可能有额外的跳转，这会改变内存访问模式并可能导致额外的分页和/或缓存未命中。旧版本的函数可能会继续驻留在可执行文件中，即使它们从未被调用过。这也会导致二进制膨胀和性能下降。而且您当然不能将链接时代码生成与增量链接一起使用，因此您会错过更多优化。
如果您要为测试人员提供调试版本，那么这可能没什么大不了的。但是您的候选版本应该在发布模式下从头开始构建，最好是在具有受控环境的专用构建机器上。
Visual Studio 在部分（增量）构建方面存在一些问题，（我大多遇到链接错误）有时，完全重建非常有用。
在编译时间长的情况下，有两种解决方案：