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

Question

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:

• Large compile times.
• Classes that normally should be Private need to be Public in order to be accessible by other projects in the same layer.
• I've recently started using the profiler Eqateq. The trial version allows profiling up to 10 dlls. My situation obviously complicates using this application.
• Keeping track of the references between projects is quite complicated. I'm sure there are a lot of unused references between projects.

In contrast, I haven't found an advantage of this situation.

So, my questions are:

• When do you decide to create a new project instead of maybe just creating a folder in the current project?
• Are there any advantages that I'm overlooking?

UPDATE:

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.

UPDATE 2:

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.

Answer 1

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.