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

user_832377 0
Viewed 4905

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.

projects-and-solutions visual-studio .net
5 Answers

I think the real issue here is one of single responsibility. I don't mean in terms of class design I mean the purpose of a .Net project.

Generally a project is used for:
1. Building some code to output a DLL, EXE, Website, API etc.
2. To control access to and structure code in a solution

From my experience, most projects are used for 2. What this leads to in large solutions is a very breadth-first structure that quickly becomes unintuitive, slows builds, slows visual studio (hello resharper!) means that huge amounts of dependencies get moved from bin to bin which makes all these DLLs that you don't actually need.

For example, if c# access modifiers could be expressed at namespace boundaries (instead of Project) then we wouldn't need to do this and could have meaningful intuitive namespace hierarchies where you would only need a project if you actually need to produce a DLL. Of course I haven't completely thought this through but I feel like something isn't quite right with having so many projects in a solution.

How does Java deal with this? Do large Java projects have lots of circular dependencies?

My answer to the question is to have as few Projects as you can get away with.

user_28104000
Related