I'm specifically interested in solution load times & build times - does fewer solutions mean better performance?
Note that I'm not referring to the performance of the built application.
Are load times and build times more efficient when working with a smaller number of projects?
As a guide, we have 50-60 projects in our Visual Studio solution.
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.
(I'm specifically interested in solution load times & build times - does fewer solutions mean better performance?)
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.
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 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.
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.
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...
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.
And some Microsoft words...
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
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.
© 2022 - 2024 — McMap. All rights reserved.
