解决方案中项目数量最多
对于 VS 2005，是否存在会导致性能问题的最大项目数。 我们现在拥有多达 25 个项目，并且还在不断增加。 我们是否应该引用这些二进制文件，或者是否将应用程序逻辑分解为太多不同的项目。 最近似乎开始成为一个大的性能问题。
for VS 2005 is there a max number of projects that will cause performance issues. We have now up to 25 projects and growing. Should we making these binary referenced or are we breaking out our application logic into too many different projects. Seems to start to be a big performance issue lately.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
拥有太多 DLL 文件可能会导致运行时成本增加，因此我建议您尽量减少项目数量。 创建多个解决方案也是一种选择，但尝试使解决方案彼此独立，以便您不必跨多个解决方案调试和实现新功能 - 这可能很麻烦。
看看这篇文章：项目反模式：Visual Studio 解决方案文件中的许多项目。
Having too many DLL files can cost you at run-time so I would recommend that you try to minimize the amount of projects. Creating several solutions is also an option but try to make the solutions independent of each other so that you don't have to debug and implement new features across several solutions - that can be cumbersome.
Take a look at this article: Project anti-pattern: Many projects in a Visual Studio Solution File.
所有 25 个项目是否都存在依赖链？ 如果某些项目不依赖于其他项目，请将它们放入自己的解决方案中。
如果不需要并且通常不会编译整个解决方案，请不要编译。 通常你可以右键单击刚刚修改的项目并编译它。 VS会找出哪些依赖项目需要重新编译。
除非您打算遇到断点，否则请使用“启动而不调试”。
有些 DLL 是否稳定并且很长时间没有改变？ 它们也不必出现在您的解决方案中。
除非确实必要，否则不要搜索整个解决方案。
真正的限制是人类的思维。 一个项目中可以处理多少个文件？ 此外，除非您使用 ndepends 来跟踪依赖关系，否则在一个项目中放入许多类可能会导致太多类依赖于其他类，从而使更改变得更加困难和风险更大。
Is there a chain of dependency through all 25 projects? If some projects aren't dependent on others, put them in their own solution.
Don't compile the whole solution if you don't have to and one usually doesn't. Usually you can right click on the project you just modified and compile just that. VS will figure out which dependent projects need to be re-compiled.
Use "start without debugging" unless you are planning to hit a break point.
Are some DLLs stable and haven't changed in long time? They don't have to be in your solution either.
Don't search entire solution unless you really have to.
The real limitation is the human mind. How many files in one project can one deal with? Also, unless you are using ndepends to trace dependencies, putting to many classes in one project can lead to too many classes depending on other classes, making changes harder and riskier.
通常，我们会尝试将解决方案中的项目数量控制在 10 以下。10 个之后，编译时间和“项目重新加载”时间就会开始变慢。
但这里的主要问题是为什么你有 26 个项目？ 一个简单的网站只能有 1 个项目，同时将数据层、业务层、表示层都保留在同一个项目中。
如果您仅针对这 3 层内容拆分项目，我建议您修改此内容。 例如，我们有 3 个第 3 层项目。 我们在单独的组件中设置 3 层的原因是，我们稍后会在项目中执行其他软件来使用数据层。 将业务层保留在主演示项目之外，使我们能够轻松地对业务层进行单元测试，同时将无用的依赖项保留在演示层之外。
因此，总的来说，将项目数量控制在 10 个以内，并检查是否可以将一些项目合并在一起。 它会节省您在编译时和构建时的时间。 管理这些 DLL 也将更加容易。
Normally we try to keep the amount of projects within a solution under 10. After 10, you start to have slow compile time and slow "project reload" time.
But the main issue here is why do you have 26 projects? A simple web site could only have 1 project while keeping the Data Tier, Business Tier, Presentation Tier all inside the same project.
If you are splitting projects only for this 3 tier stuff, I suggest that you revise this. as an example, we have 3 projects for the 3 tier. The reason we have 3 tiers in separate assembly is that we are execting other software to use the data tier later in our project. Keeping our business layer outside the main presentation project allows us to easily unit test our business tier while keeping useless dependencies outside the presentatier tier.
So, overall, keep projects under 10 and review if you can merge some projects togheter. It will both save you time at compile time AND at build time. It will also be more easy to manage those DLLs.
我想说的是，它是在构建时而不是运行时花费你的。 越少越好，但也许您并不总是构建所有这些。 如果是这种情况，那么你应该减少用量。 否则将它们分成不同的解决方案。 然后，只有构建服务器需要构建所有这些，并且每日构建需要整夜来构建;-)
I would say it costs you at build time not runtime. And less is faster, but perhaps you don't always build all of them. If that is the case then you should reduce the amount. else split them up in different solutions. Then only the build server will need to build all of them and a daily build has all night to build ;-)