我对解决方案加载时间特别感兴趣构建时间 - 更少的解决方案意味着更好的性能吗？
请注意，我不指的是构建应用程序的性能。
使用较少数量的项目时，加载时间和构建时间是否更有效？
作为指南，我们的Visual Studio解决方案中有50-60个项目。
答案 0 :(得分：13)
帕特里克·斯马奇亚（Patrick Smacchia）的相关主题描述了拥有少量集会的好处（此后项目数量很少）。他准确地谈到了装配数量如何影响构建时间和其他因素。（我特别感兴趣的是 解决方案加载时间＆amp;建造时间 - 更少的解决方案意味着更好 性能？）
我鼓励您阅读Patrick博客。他有很多关于代码组件化的文章。
Advices on partitioning code through .NET assemblies
Lessons learned from the NUnit code base
从我个人的经验来看，拥有几十个项目的解决方案是一件痛苦的事。拥有10个以上项目的IMO将导致明显的维护问题并影响您的工作效率。
答案 1 :(得分：4)
我依赖于你的项目，大部分时间我都在使用10-15。 项目越少，构建时间越短。
我通常拥有的项目是：
其中一些我将分成3-4个其他项目。我也有NUnit测试项目。
答案 2 :(得分：3)
我去过各个公司，这些公司有很多项目，每个项目只有几个班级，很容易合并到一个项目中。根据我的经验，这也有维护/可管理性的好处。 （当然不要无所事事 - 只是明智的。）
如果您实际上有大量合理的项目，只考虑其中很多，请考虑尽可能地拆分解决方案。如果他们都是小项目，请考虑将其中一些项目结合起来。如果你还没有发现自己正在等待Visual Studio（开放/建设），那么不要太担心。
答案 3 :(得分：3)
在解决方案中包含太多项目是个坏主意。它会影响构建时间。请参阅使用多个构建工具对构建时间进行比较的this article。根据文章，Visual Studio每个项目需要2秒，即使项目不是构建的一部分。
这也符合我的经验，Visual Studio是最慢的构建工具之一。在Visual Studio 6和2006之间，对于一个相对简单的C项目，我的构建时间从1分钟变为5分钟。
答案 4 :(得分：3)
晚会，但到目前为止，没有一个答案提到构建配置。 您可以在解决方案中拥有大量项目，而无需在每次运行时都构建它们。单击Debug / Release组合并创建一个新的构建配置 - 您可以在那里决定要构建或不构建的项目。
为什么这样？我这样做是为了让我可以随意“去定义”，这样我就可以快速地将项目交换到我的构建中，而无需完成所有Add项目的痛苦。
另请注意，如果您有解决方案文件夹，则可以右键单击并构建该文件夹，该文件夹将构建文件夹中的所有项目。
答案 5 :(得分：1)
我在创建大量小项目时遇到的问题是：
1 / 封装：您希望在两个项目之间共享的类，方法或属性必须是公共的，因此可以从任何地方看到。你拥有的项目越多，你披露一些秘密的可能性就越大......
2 / 程序集总数：正如 Aku 所写，更少的项目会减少程序集。由于每个项目在本地复制它们使用的程序集，因此您可以在文件夹中获得（n *（n - 1））/ 2个程序集（程序集1的49个副本，程序集2的48个，...）。对于50个项目，这是 1176 文件！ =＆GT;好吧，你可能要少得多（200？），但它仍然需要在这里和那里得到一个或两个过时的副本......
答案 6 :(得分：1)
我参与了一个包含大量项目的项目，范围在50-60，我发现与开发人员懒惰/健忘相关的问题相比，加载时间长是可以接受的。
许多项目依赖于基础库，因此需要在更改基础库时重建。由于项目在任何给定时间都有一些变化，开发人员只能处理子集意味着如果他们是懒惰的，他们将不会在从CM工具收到更新时重建整个应用程序。然后，他们可以花费大量时间来解决事情，解决事情被破坏的原因。如果VS已知整个依赖关系树并且快速构建全部可以使其全部正常工作，则全部解决了。
我意识到一个优秀的开发人员会知道这一点并默认情况下这样做，但并不是每个人都很棒，有时即使是伟大的人也有这些日子。
答案 7 :(得分：1)
还有一些微软的话......
答案 8 :(得分：0)
在我看来，这只是个人组织和秩序的问题。如果您希望在同一解决方案下有许多以某种方式相互连接的项目，您可以这样做。我想你只需要考虑一下你是否真的需要它们。每个解决方案都没有神奇的最大项目数
答案 9 :(得分：0)
我尝试遵循的一般做法是每个解决方案4-5个项目。
这通常符合我们的风格以及我们如何实施它。如果有必要，我们也可以在其中包含其他内容，但这些实例并不像我们这四个那样普遍。