In the company I currently work for, we support 4 windows applications that are somewhat related. For each application we have a solution, each ranging from 50 to 100 projects. There are probably 40 or 50 projects that are shared between one or more solutions.
Just to give you an idea, the larger solution has almost 90 projects, 20 of which are UI projects (main application, custom controls projects, UI helper projects), another 20 are Business Layer projects, there's probably 30 or 40 Data Access layer projects and the rest are Windows Service projects and specialized projects
I've always felt that there are too many projects in each solution. Sure, we're talking about large applications, but I don't see why many of the projects couldn't be consolidated. In my previous company, we actually had one single project for the business layer, one single project for the DAL and obviously one project for each windows or web app.
Here are some of the problems I've come across due to the large amount of projects:
In contrast, I haven't found an advantage of this situation.
So, my questions are:
Keep in mind that I'm not proposing having one single project for everything. At a bare minimum, there should be one project for the DAL, one for the BL and one for every UI app. And I realize even that is unrealistic for most applications. What I'm trying to get at is, what are the best practices for defining the level of "single responsibility" for an assembly? I mean, this is a very subjective matter that, if taken to the extreme, would lead to having one assembly per class.
All three answers provided valuable information, but as I can only select one I'm choosing Doc's for his comment on how to determine the number of DAL projects. I'm also linking to other questions I just found that have related information: Here and here. I also recommend reading this article.
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.