解决方案中的大多数项目

Question

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.

Answer 1

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 .

Answer 2

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.

Answer 3

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.

Answer 4

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 ;-)