- You’ve got more than one (Visual Studio) solution depending on the outputs from another.
- Your checking binaries (.dlls, etc.) that aren’t third party into your version control system, as you do with third party stuff.
- You have clumps of projects that are highly cohesive. You feel you need to organize them. A solution seems like a good organizational unit above projects.
- More than one team is working on dependants. To avoid integration pain, they want to work on just their code, using a static version of the dependency (a compiled branch.)
What to Do
- Put all the projects into one solution.
- Use folders to organize them, instead of solutions.
- If there are multiple teams, they all work on their projects in the same solution.
- If it takes too long to build, unload projects you’re not changing right now. Load them again or use a command line build before checking in or doing cross project refactorings.
- Reduction in build and version control complexity
- Reduction in code ownership
- Less big-bang when updating dependencies.
- More “we’re all in this together”
- For web applications, you might end up using server resources far more efficiently if the modules can share an app pool. This can make a huge difference when you have a lot of projects.
- If the project really, really needs to be complicated (say, 100+ screens/pages, each with 20+ controls/fields, or more than 15 developers) then it makes sense to separate them, at the same time spending effort to minimize coupling between the solutions. The idea is to make this more of a last resort. Rough estimate: solution/developer should be about 1/15.