The next problem we would have is with our release schedule. We do patch-like releases on a daily basis and our remote users only have to download the dlls that have actually changed. If it was all in one solution, we would be worse than i-tunes for making people having to constantly reinstall our product.

I can appreciate that the blog was written based on smaller projects the author has experience with, but good practice should be the same regardless of the scale. if your project is small that should make it easy to keep it modular.

Of course there ultimately has to be a thought process for what constitutes a time for a new project, and some people may take this too far. If you are studying at university then your teachers may get you to split things which seem a bit silly at the time, but in that case you are in an academic environment and you’re assignment probably isn’t so big to warrant so many projects but what you are learning is how to split a solution into subsystems, and write reusable code. If you reject these principals how will you cope when you work somewhere like I do and have over a million lines of code to manage.

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…