Why add a project to a solution rather than a folder?

Question

I'm encountering a weird solution structure in my company—the different layers of the application are organized in folders (instead of in projects).

For instance, there are folders within the solution named "DAL", "BL", "WCFClient," etc. I've never seen that before, but can't quite put my finger on what troubles me about it.

Can anyone tell me if there are any cons (or possibly pros) for this folder-based organizational approach?

Answer 1

Here are few cons and pros for C# (.NET) projects:

Pros:

• Multiple projects can cause circular reference problems if classes are not put into correct assemblies. See http://en.wikipedia.org/wiki/Circular_reference and Why are circular references in Visual Studio a bad practice?

• Multiple projects leads to multiple dll files. Handling those MIGHT be tricky if they are piling up a lot. For instance we had ~200 files in our project and TeamCity sometimes lost few files at build process. We got around of it by zipping our files before deploying them.

Cons:

• Code is not modular. You cant reuse parts of it in other projects. I think this is one of biggest downsides. For instance if you want to use one class from assembly. You have to add reference to whole project.
• One project can grow HUGE and cause multiple problems. Starting from name collisions (In VB.NET there are no namespaces automatically created for folders) into deep folder trees.
• Searching from huge project is harder than from small one (depending how accurate the foldering is)