我们有几个（大约10个）C ++ DLL项目，这些项目在多个解决方案之间共享。
我（可能天真）的信念是，如果我连续构建每个解决方案 - 在第一个解决方案的构建之后，其余的应该很快构建。对于“编译代码”的东西（谢天谢地）这是正确的，但是由于编译器/链接器仍然做了一些看似不必要的工作，所以看起来不太正确。
为了简化问题，我创建了两个共享一个有效空win32 DLL项目的解决方案。在每次构建之后，我得到以下内容（'正常'详细程度输出 - 我现在将为您省略'详细'和'诊断'：
1>InitializeBuildStatus:
1> Creating "Debug\Prj_1.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
1> ClCompile:
1> All outputs are up-to-date.
1> All outputs are up-to-date.
1> Link:
1> All outputs are up-to-date.
1> Prj_1.vcxproj -> E:\code\C++\CommonLibTest\CLT_1\Debug\Prj_1.dll
1> Prj_1.vcxproj -> E:\code\C++\CommonLibTest\CLT_1\Debug\Prj_1.pdb (Full PDB)
1> FinalizeBuildStatus:
1> Deleting file "Debug\Prj_1.tlog\unsuccessfulbuild".
1> Touching "Debug\Prj_1.tlog\Prj_1.lastbuildstate".
这是我关注的“链接”步骤 - 特别是(Full PDB)。这在测试情况下并不重要，但是在构建我们更大的解决方案时，它往往会给构建过程增加一些烦人的时间（构建'应该花费几秒钟，最终花费大约一分钟）。
使用'详细'构建输出，我看到以下消息：
由于命令更改而强制重建所有源文件 自上次构建以来的行。
我在本网站上看到过与此消息相关的其他帖子，但这些帖子中没有提及对我有帮助。
我尝试了上面带有和不带预编译头的简单测试用例，但没有改变行为。
我唯一的解决方案是将中间目录更改为解决方案的output-folder中的子文件夹。然而，这并不理想，因为你必须单独构建每个项目......最终需要花费更长的时间。