Most projects within the solution

Question

for VS 2005 there is a maximum number of projects that can cause performance problems. Now we have up to 25 projects and are growing. Should we make these binary links or will we break our application logic into too many different projects. This seems like a big performance issue lately.

Answer 1

Too many DLL files can cost you at runtime, so I recommend that you try to minimize the number of projects. Creating multiple solutions is also an option, but try to make the solutions independent of each other so that you do not have to debug and implement new functions in several solutions - this can be cumbersome.

Take a look at this article: Project anti-pattern: many projects in the Visual Studio solution file .

Answer 2

Is there a dependency chain for all 25 projects? If some projects are independent of others, put them in your decision.

Do not compile the whole solution if you do not need it, and usually not. You can usually right-click on the project that you just modified and compile just that. VS will figure out which dependent projects need to be recompiled.

Use "start without debugging" if you do not plan to hit the breakpoint.

Are some DLLs stable and have not changed for a long time? They also should not be in your decision.

Do not search for the whole solution unless you really need to.

The real limitation is the human mind. How many files in one project can you handle? In addition, if you do not use ndepends to track dependencies, using many classes in one project can lead to too many classes depending on other classes, which will make changes more complex and more risky.

Answer 3

Usually we try to keep the number of projects within the solution to 10. After 10, you start a slow compilation time and a slow project reload time.

But the main problem here is why do you have 26 projects? A simple website can have only one project, while preserving the data level, business level, presentation level within the same project.

If you only split projects for this three-tier material, I suggest you reconsider that. As an example, we have 3 projects for the 3rd level. The reason we have 3 levels in a separate assembly is because we use other software to use the data layer later in our project. Keeping our business layer outside of the main presentation project allows us to easily unit test our business layer while maintaining useless dependencies outside the current layer.

So, in general, keep projects under the age of 10 and analyze if you can combine some togheter projects. This will save you time during compilation and during build. It will also be easier to manage these DLLs.

Answer 4

I would say that it costs you at build time, and not at runtime. And less is faster, but perhaps you don't always build them all. If so, you should reduce the amount. otherwise divide them into different solutions. Then only the build server will have to build all of them, and the daily build should be built all night; -)