Visual Studio solutions: Do these solutions have too many projects?

It looks as though this is a classic example of pre-mature optimisation. Developers in your team seem to be creating many projects probably due to historic architectural reasons and you are doing the right thing by questioning this approach.

My personal opinion is to start with one project per layer (as you mention) like one for GUI, one for Business Layer, one for DAL etc. Additional projects for your solution should only be created when a specific need arises and not prematurely. At this point you can refactor your solution to move a project "Folder" into its own separate project.

This will ensure that : - build times are faster - You have the exact amount of projects your project requires - You have documented reasoning as to why you created a specific project (what need it fulfils)

Creating many specific projects in a solution is simply "Over engineering". You wouldn't over-engineer your code and create classes in places that were not required. You would refactor your code to include a class with a single responsibility when one was required. The same applies to solutions and projects.

We are talking mainly about .NET projects, right? Having your application split into different projects/assemblies forces you to avoid cyclic dependencies between those projects, since the C# and VB.NET compilers do prohibit this. If you put a everything into one big project, every class can reference every other class in that project, allowing you to create a real dependency nightmare. If you are going to use unit tests and development in a team, it is mostly easier if team members can work at different, isolated DLLs and test them separately.

The "keeping track of references" part of your question: if you put everything into one big DLL, you have the same references between your classes as if you have separate DLLs, but you cannot control them any more. Same goes for "private" classes (you mean "internal", I think?)

What I cannot tell you, of course, is, if your 90 projects are well chosen units of work. That's a question of "single responsibility", correct level of abstraction and resulting dependencies, only to be answered by someone who knows your application system in detail.

EDIT: so far I have read some articles (like this one) about bringing down compile times by defining the component boundaries by namespaces, and putting several components into one physical assembly / one VS project. To make this approach feasible, one needs probably a tool like NDepend or something similar to make sure there are no cyclic dependencies between components. For big projects, this may probably the better alternative.