As for the number of projects… as long as there is no clear-cut benefit or reason to putting something in a different project, it’s completely pointless IMO. And once your solution becomes big enough, the extra compilation time definitely comes back to bite you.

Compilation: In the past I have been tempted just to reference binary output of shared libraries but didn’t find a way to specify linking to difference assemblies based on the RELEASE/DEBUG build option. Maybe I will go back to doing this but always referencing the RELEASE assembly.

I certainly don’t agree with the 1 project approach though

proper release management and branching avoids that, and a host of other potential issues as well

About the navigation… i think it really depends on a lot of things. i wouldn’t just use a couple of top-level folders and put everything directly underneith them either. I pretty much go with top level folders for everything that most people would use different projects for and then i probably have a similar folder structure as most people would have. I just find it a lot easier to have it all within the same project. It’s probably just me though

As for reuse, i agree that once you want to reuse certain parts that would be a valid reason to put those parts in a separate project. I don’t think it should be a rule though… if there’s an advantage to splitting it up for reuse then by all means do so. If there’s really no disadvantage to referencing an entire assembly just to reuse a couple of classes, then i don’t really see the point in splitting it up either. It’s something you should look at on a case by case basis probably

the layer per assembly thing… i still don’t see the point as the whole “it’s cleaner” argument just seems purely theoretical to me. As long as there is no practical advantage, i don’t see the point. Obviously, this changes when you have multiple physical deployments, but if that’s not the case, why bother?

@LukeB:

Wouldn’t the client’s application have to be restarted anyway before the fixed assembly would be used by the application? It might as well be just one assembly then

Unless you ment updating a server-side assembly without affecting client downtime, but then you’d already be using different assemblies anyway

Got projects on the brain today.

1) Less project doesn’t really, in my experience, lead to easy navigation on a large project. You just end up with more folders and more folder hierarchy which mean that related classes spread out more. So if you keep all your domain classes in a folder then that folder will be large or have a lot of hierarchy, do the same with other aspects of the codebase (controllers, views, factories, config…) you end up navigating around a lot anyway.
2) Less project is faster – Agreed, but then by splitting things out into small(er) coherent chunks you can include just what you need in the solution. I don’t bring in a mothership project with all its tests/code just so I can reuse the projects that I really am interested in. Also I think Michael Feathers had an interesting point on this in his book, where you only depend on an interface and as long as the implementation doesn’t change you don’t need to rebuild.
3) Reuse – I haven’t experienced people moving things out for future reuse but I agree that’s bad, however in my experience reuse happens a lot and thats definitely a place where more targetted projects help.
4) Layer Per Assembly – I agree, basically, with that approach and its not about trust, I’d do it working on my own as I just find it far cleanrer.

Anyway I’m not overly happy with a lot of projects but one project doesn’t fit my needs either (reuse/dependencies/navigation) so I’m really wondering if we need a more virtualized view. Folders/projects providing one view of our development efforts just doesn’t seem enough…