Visual Studio 9 解决方案中的项目数量是否会影响解决方案加载和生成时间？
我对解决方案加载时间和解决方案特别感兴趣 构建时间 - 更少的解决方案是否意味着更好的性能？
请注意，我并不是指所构建应用程序的性能。
处理较少数量的项目时，加载时间和构建时间是否更高效？
作为指导，我们的 Visual Studio 解决方案中有 50-60 个项目。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
这是 Patrick Smacchia 的 相关主题，描述了拥有少量程序集（以下简称少量项目）的好处。 他准确地谈到了程序集数量如何影响构建时间和其他因素。
我鼓励您阅读帕特里克的博客。 他有很多关于代码组件化的文章。
有关分区的建议通过.NET程序集进行代码
从 NUnit 代码库中汲取的经验教训
有关如何组件化现有代码的提示。
根据我个人的经验，用几十个项目来提供一个解决方案是很痛苦的。 IMO 拥有超过 10 个项目将导致明显的维护问题并影响您的生产力。
Here is related topic by Patrick Smacchia describing benefits of having small number of assemblies (thereafter small number of projects). He talks exactly about how number of assemblies can affect build time and other factors.
I encourage you to read Patrick blog. He has a lot of articles about code componentization.
Advices on partitioning code through .NET assemblies
Lessons learned from the NUnit code base
Hints on how to componentized existing code.
From my personal experience it's a pain to have a solution with a few dozens of projects. IMO having more than 10 projects will lead to noticeable maintenance problems and affect your productivity.
我取决于你的项目，大多数时候我与 10-15 一起工作。
项目越少，构建时间越短。
我通常拥有的项目有：
其中一些我将分成 3-4 个其他项目。 我也会有 NUnit 测试项目。
I depends on your project, most of the time I work with 10-15.
The less projects the shorter the build time.
Projects I typically have are:
Some of these I would separate into 3-4 other projects. I would also have NUnit test projects as well.
50-60 对我来说听起来很多。 我发现对于很多的项目，打开 Visual Studio 可能需要很长时间。 如果您更改许多其他项目所依赖的项目，构建时间可能会很糟糕，但我不知道 10 个项目（每个项目有 20 个类）和 100 个项目（每个项目有 2 个项目）之间有什么不同。 （换句话说，我不确定每个项目的构建开销。）即使您不更改任何内容，大概每个项目都必须检测是否需要重建任何内容- 我无法想象这是免费的，但是如果不使用您自己的代码进行尝试，就很难给出更明确的信息。
我曾在多家公司工作过，这些公司有很多项目，每个项目只有几个类，这些类可以很容易地合并到一个项目中。 根据我的经验，这也具有维护/可管理性的好处。 （当然，不要随意这样做 - 只是要明智。）
如果您实际上有规模合理的项目，而且数量很多，请考虑在可能的情况下拆分解决方案。 如果它们都是小项目，请考虑将其中的一些项目合并起来。 如果您发现自己没有等待 Visual Studio（打开/构建），那么不必太担心。
50-60 sounds like a lot to me. I find that with lots of projects, opening Visual Studio can take a long time. Build time may be bad if you change a project which lots of other projects depend on, but I don't know how different that is between 10 projects with 20 classes in each and 100 projects with 2 projects in each. (In other words, I'm not sure of the per-project overhead in building.) Even when you don't change anything, presumably each project has to detect whether or not it needs to rebuild anything - I can't imagine that's free, but it's hard to give anything more definite without trying it with your own code.
I've been in various companies which have a bunch of projects each with just a few classes in - classes which could very easily be amalgamated into a single project. That has maintenance/manageability benefits as well, in my experience. (Don't do it willy-nilly, of course - just be sensible.)
If you've actually got sensibly-sized projects, just a lot of them, consider splitting the solution up if possible. If they're all tiny projects, consider combining some of them. If you don't find yourself waiting for Visual Studio anyway (opening/building) then don't worry too much.
在解决方案中包含太多项目是一个坏主意。 它会影响构建时间。 请参阅这篇文章，该文章对几种构建工具的构建时间进行了比较。 根据该文章，Visual Studio 每个项目需要 2 秒，即使该项目不是构建的一部分。
这也符合我的经验，即 Visual Studio 是可用的最慢的构建工具之一。 在 Visual Studio 6 和 2006 之间，对于一个相对简单的 C 项目，我的构建时间从 1 分钟缩短到 5 分钟。
It's a bad idea to have too many projects inside your solution. It affects build time. See this article that does a comparison of build times with several build tools. According to the article, Visual Studio takes 2 seconds per project, even if the project is not part of the build.
This also matches my experience, that Visual Studio is one of the slowest build tool available. Between Visual Studio 6 and 2006, my build time has moved from one minute to 5 minutes for a relatively simple C project.
聚会迟到了，但到目前为止，没有一个答案提到构建配置。
您的解决方案中可以有很多项目，而无需每次运行时都构建它们。 单击“调试/发布”组合并创建新的构建配置 - 在那里您可以决定要构建或不构建哪些项目。
为什么要这样做？ 我这样做是为了我可以随意“转到定义”，这样我就可以快速地将项目移入和移出我的构建，而无需经历所有添加项目的痛苦。
另请注意，如果您有解决方案文件夹，则可以右键单击并在该文件夹上构建，这将构建该文件夹中的所有项目。
Late to the party, but none of the answers so far mentions build configurations.
You CAN have lots of projects in your solution without them all being built every time you run. Click on the Debug/Release combo and create a new build configuration - there you can decide which projects you want to build or not.
Why do this? I do it so that I can 'Go to definition' at will, and so that I can rapidly swap projects in and out of my build without going through all the Add project pain.
Also, note that if you have solution folders, you can right click and build on the folder, which will build all the projects in the folder.
当您创建很多小项目时，我看到的问题是：
1/ 封装：您想要在两个项目之间共享的类、方法或属性必须是公共的，因此是可见的来自各地。 你拥有的项目越多，你就越有可能泄露一些秘密......
2/ 程序集总数：正如Aku所写，项目越少意味着程序集越少。 由于每个项目都会在本地复制它们使用的程序集，因此您的文件夹中最多可以获取 ( n * (n - 1)) / 2 个程序集（程序集 1 的 49 个副本、程序集 2 的 48 个副本，...）。 对于 50 个项目，这是 1176 个文件！ => 好吧，你的数量可能少了很多（200？），但是到处买一两本过时的副本仍然足够了......
The problems I see when you create a lot of small projects are :
1/ Encapsulation : A class, a method or a property that you want to share between two projects have to be public and thus to be visible from everywhere. The more projects you have, the more likely it is that you are disclosing some secrets...
2/ Total number of assemblies : As Aku wrote, fewer projects meens fewer assemblies. Since each project copy locally the assemblies they use, you could get up to ( n * (n - 1)) / 2 assemblies in your folders (49 copies of assembly 1, 48 of assembly 2, ...). For 50 projects, this is 1176 files ! => Ok, you probably have a lot less (200 ?), but it is still enought to get a copy or two outdated here and there...
我负责一个包含 50-60 个项目的项目，我发现与开发人员懒惰/健忘相关的问题相比，较长的加载时间是可以接受的。
很多项目都依赖于基础库，因此当基础库发生变化时需要重新构建。 由于项目在任何给定时间都可能处于某种变化中，因此让开发人员只处理一个子集意味着，如果他们很懒，他们将不会在从 CM 工具收到更新时重建整个应用程序。 然后，他们可以花费大量时间尝试修复问题，并了解问题出现的原因。 如果 VS 知道整个依赖树并且快速构建所有可以使其正常工作，那么这一切都可以解决。
我意识到优秀的开发人员会知道这一点并默认这样做，但并不是每个人都很棒，有时即使是伟大的开发人员也会有休息的时候。
I work on a project with a large number of projects, in the realm of 50-60, and I have found that the long load times are acceptable compared with the problems associated with developer lazyness / forgetfulnes.
Lots of the projects are dependent on base libraries, and thus need to be rebuilt when the base library is changed. As the projects can be in some flux at any given time, having developers only work on a subset means that if they are lazy they will not rebuild the entire application when an update is received from the CM tool. They can then spend a huge amount of time trying to fix things realizing why things are broken. This is all solved if the entire dependency tree is known by VS and a quick build-all can make it all work properly.
I realize that a excellent developer will know this and do it by default, but not everyone is great, and sometimes even the greats have off days.
还有一些 Microsoft 的话...
http://tfsguide.codeplex.com/Wiki/View.aspx?title=Chapter%203%20-%20Structuring%20Projects%20and%20Solutions%20in%20Source%20Control
And some Microsoft words...
http://tfsguide.codeplex.com/Wiki/View.aspx?title=Chapter%203%20-%20Structuring%20Projects%20and%20Solutions%20in%20Source%20Control
在我看来，这只是个人组织和秩序的问题。 如果您希望在同一个解决方案下有很多项目以某种方式相互连接，那么您可以这样做。 我认为你只需要考虑一下你是否真的需要它们。 每个解决方案不存在神奇的最大项目数
In my opinion it's just a matter of personal organizzation and order. If you feel like to have a lot of projects that are connected in some way each other under the same solution, you can do it. I think you just have to consider if you really need them all. There's no such thing as a magical maximum number of projects per solution
我尝试遵循的一般做法是每个解决方案 4-5 个项目。
这通常适合我们的风格以及我们如何实施它。 如果有必要，我们也可以在其中包含其他内容，但这些情况对我们来说并不像这四种情况那么常见。
The general practice I try to keep to is 4-5 projects per solution.
This generally fits our style and how we can go about implementing it. If necessary, we can include other things in there too, but those instances aren't nearly as common as these four for us.