我们的编译时间很慢，在双核2GHz，2G Ram机器上可能要花费20多分钟的时间。

这主要归因于我们的解决方案的规模（已发展到70多个项目），以及VSS（当您拥有大量文件时，它本身就是瓶颈）。（不幸的是，换掉VSS并不是一个选择，所以我不希望它沦落为VSS
bash）

我们正在考虑合并项目。我们还在寻找具有多种解决方案的解决方案，以实现关注点的更大分离，并为应用程序的每个元素提供更快的编译时间。当我们尝试保持同步时，我可以看到这将成为DLL的地狱。

我很想知道其他团队是如何处理此扩展问题的，当您的代码库达到临界数量（浪费半天观看状态栏来传递编译消息）时，您会怎么做。

UPDATE 我忽略了提及这是一个C＃解决方案。感谢所有C ++的建议，但是距离我不得不担心头文件已经过去了几年了。

编辑：

到目前为止已经有用的不错的建议（不是说下面没有其他不错的建议了，只是有什么帮助了）

• 新的3GHz笔记本电脑-失去管理的能力使管理时产生奇迹
• 在编译过程中禁用反病毒
• 在编译过程中与VSS（实际上是网络）“断开连接”-我可能会让我们完全删除VS-VSS集成，并坚持使用VSS UI

仍然不能通过编译来简化工作，但是一点点都可以。

Orion在评论中确实提到了仿制药也可能发挥作用。从我的测试来看，确实确实对性能的影响最小，但是不足以确保-
由于光盘活动，编译时间可能不一致。由于时间限制，我的测试未包含实时系统中出现的那么多泛型或代码，因此可能会累积。我不会避免在应该使用泛型的地方使用它们，只是为了提高编译时的性能。

解决方法

我们正在测试在新解决方案中构建应用程序新区域的实践，根据需要导入最新的dll，并在我们满意时将它们集成到更大的解决方案中。

我们还可以通过创建临时解决方案来对它们进行处理，这些临时解决方案仅封装了我们需要处理的区域，并在重新集成代码后将其丢弃。我们需要权衡重新集成此代码所花费的时间与我们在开发过程中没有像Rip
Van Winkle这样的快速重新编译经验所获得的时间。