问如何拆分Visual解决方案？

EN

没有什么好办法做这件事。这些工具的构建并不是考虑到这一点。相反，您应该尽可能多地将您的项目组合在一起。即使代码数量相同，构建的运行速度也会快很多倍。

您必须克服这样的想法，即要有良好的抽象，就需要单独的项目。这似乎是强制分离的一种非常干净的方式。但是用这个工具链是不值得的。而是使用语言特性；类、命名空间等等。

另一种可能需要考虑的方法是，只需卸载未使用的项目，只需右键单击并卸载不工作的项目，on...this就会产生一个更快的Visual。它把很多东西保存在VS的记忆之外。

您可以做的其他事情是编辑构建定义并删除任何未经修改的项目(取决于您如何链接are...you，知道需要/更新/不需要什么)。

解决方案 ->向右单击-> 配置管理器 ->，在任何不更改且由于其他原因不需要每个构建的项目上取消 build 。这将通过使用这些项目的上一次构建的输出来加快构建速度，无论这些项目将二进制文件转储到哪里。

注意：，您仍然可以右键单击一个项目并构建以更新它的输出，然后重新构建解决方案以获得latest...you可以这样做，而不是来回更改构建配置以包括它。

更新

本着遵循性能路线的精神(例如，等到VS 2010真正开始)，您是否采取了其他堆栈溢出问题中列出的措施：Visual上编译时间非常慢和Visual优化？这些都会带来很大的不同，并且在我们等待VS 2010装船的时候，性能可能会达到一个可接受的水平。

还有一些可以对性能产生良好影响的因素：

• 我强烈推荐SSD如果这是一种选择。它们很昂贵，但绝对值得，解决方案中的文件越多，它们的回报就越大。当我们在工作中订购新机器时，整个开发团队都使用了SSD，两者之间的差别是惊人的。当您处理一个大型解决方案时，它正在旋转驱动器，将物理头切换到数千个位置，只为了读取文件.这是SSD获胜的地方，寻求时间实际上是0ms。
• 按照同样的思路，一个免费的解决方案是一个很好的绘图器(只有在物理上，不分解一个SSD)，就可以制作一个大的difference...if --您使用的是将visual放在心上的东西。我推荐MyDefrag (免费软件)，因为它的本机解帧算法使目录结构保持在脑海中，所以至少一个物理驱动器不会花费太多时间来切换解决方案中需要的文件，它们都在磁盘上非常接近。
• 有了以上的SSD建议，请记住，SSD性能在便宜和快速之间有很大的差距，在这里做一点研究。不要担心你的系统，使用一个免费的实用程序比如gParted，你可以很容易地移动你的整个操作系统驱动器，你的旧驱动器将仍然是一个backup...as，只要SSD可以从你的C上的数据，你是好的。

您可以创建多个解决方案，并将任何项目添加到您喜欢的每个解决方案中。

您希望构建的项目可能与其他项目有依赖关系。在这种情况下，您需要从使用" project“引用(whch引用解决方案中的任何其他项目)改为使用文件引用(在这里您引用了项目创建的程序集.dll )。

因此，让我们把它们看作是“库”(编译一次，然后大量使用)和“核心”项目(您正在进行大量更改)。制定包含“库”项目的解决方案，并(最好)添加一个构建后步骤，将结果的调试/释放dll复制到共享库文件夹中。将核心项目添加到新的解决方案中。将所有核心解决方案引用更改为通过共享文件夹中预先构建的二进制dll引用库(请参阅release，以便最终版本正常工作)。

如果更改了库，则需要构建库解决方案来重新构建库解决方案，然后使用核心解决方案重新构建依赖于库的应用程序。(因此，在核心解决方案中而不是在库中放置任何频繁更改的代码是一个好主意。当项目成熟时，您可以在以后的某个日期将其移动，并且/或如果需要在一段时间内对核心项目进行大量修改，可以将其转换为核心项目)。

2018年编辑这些天，图书馆可以分发使用当地nuget或npm服务器，这将是一个首选的选择，除非有特定的理由不采用这种方法。

最后一个选项是，如果构建库需要一段时间，而且更改频率很低，那就是让它们“预编译”库--将最终的dll文件签入到源代码管理中，您的团队成员只需获得最新版本，就可以针对库进行构建，而根本不需要为它们获取或构建源代码。(要更新这些库，您必须记住在构建二进制.dll文件之前先签出它们，然后在重新构建它们之后再签入它们，因此您必须权衡它们的优点(更快、更容易构建)和缺点(对库进行更多的修改，在源代码管理中使用更大的二进制文件)。