我有两个解决方案S1，S2并且引用了两个C ++项目：
Project S1 S2
A x x
B x x
C x
D x
ProjectA和B是静态库，在两个解决方案中都使用，而CandD是使用A和B和的可执行文件，它们分别是一个解决方案的一部分。
如果我对项目进行更改，VS必须重新编译该项目及其使用者，这是预期的行为。但是，如果我构建其中一个解决方案，则另一个解决方案的构建将无效，这意味着VS会重新构建所有内容，尽管未进行任何更改。
例：
我对A和进行了更改B。现在我建立S1它建立A，B和D（全部正常为止）。然后我构建S2它建立A，B和C（为什么A和B重建？）。现在我建立S1试（注意，因为我建造它的最后一次，我还没有做出任何改变）再次建立A，B和D。
为什么VS每次都要重建这些项目？
所有项目均使用C ++ 17编写，Visual Studio版本为15.9.10（今天的最新版本为03/28/19）。
有两个原因：
默认情况下，构建项目会将目标文件和最终二进制文件输出到引用该项目的解决方案的子目录中。因此，解决方案1和解决方案2各自具有自己的A.lib和B.lib副本以及它们自己的所有目标文件副本，以构成这些库。如果您为解决方案1重建项目，则该目录树中的副本将具有已更新的库，但解决方案2的树则不会-必须重新构建它。
您可能会搞乱一堆项目和解决方案设置，以实际共享所有二进制文件，但是我不确定这是否值得，还是不确定用于构建的依赖项检查程序是否可以识别它。
解决方案1和解决方案2可能要使用不同的编译器选项来构建共享项目。例如，也许一个使用MBCS，而另一个使用“ Unicode”。如果您尝试共享共享二进制文件，那么它将无法与需要其他选择的解决方案一起使用。
您也可以通过为每组选项进行不同的配置/平台组合来解决此问题。但是，这没有什么意义，因为，只要他们使用不同的选项，无论如何都将不得不重新构建所有内容。
当您跨解决方案共享项目时，您只是在共享源代码。每个解决方案实质上都有一个项目所有设置的副本（可能是唯一的）。
我在多个解决方案中共享许多项目，当我在这些解决方案之间切换时，不必担心真正的库重建。
如果C和D紧密相关，那么也许您只需要一个解决方案。（一个解决方案当然可以有许多产生可执行文件的项目。您可以在调试时快速轻松地更改要启动的项目。）然后您会发现每个库仅重建一次，但是更改一个库也会导致两个可执行文件都被重新编译。重新建造。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句