At work, we've developed a custom ASP.NET Web Portal (That's very similar to iGoogle). We have "Apps" (self-contained, large web forms) and "Modules" (similar to Google Gadgets).

Currently, we use a single-solution model. Right now, we have:

• 3 core projects
• 60 application projects
• 80 module projects

To reduce copy and pasting between projects, we're going to factor out common functionality (Data Access, Business Logic) into separate projects. I'd also like to introduce Unit Tests, which is going to increase the number of projects even more.

We've already reached the point where Visual Studio is choking on the number of projects. We generally only load the 3 core projects and then whatever app's/module's project we're working on.

Would a different solution structure help us out? Our number of projects is only going to increase.

In general, an app or module only references the 3 core projects. Soon, apps/modules may start referencing the Data Access/Business Logic projects. But in general, apps and modules do not make references between themselves.

So to recap, what is the best practice for solution structure when there are MANY projects that use a small number of core projects?