We currently have a rapidly growing C# codebase. Currently we have about 10 projects, split up in the usual categories, common/util stuff, network layer, database, ui components/controls etc.
We run into the occasional circular dependency where project x depends on something in y and vice-versa. We are looking at maybe collapsing the projects down to one and just managing using structure folders/namespaces. We have a Java project which of course organises just using folders/packages so we're not sure what, if any, benefit having multiple projects brings. None of our projects require special project properties, except the main run project, which we may kept separate (and very thin).
Does anyone have any prior experience in why one project is better/worse than multiple projects and could suggest the best approach? And also any issues with circular dependencies would be useful in either approach would be useful.
Any input appreciated.
In my experience, separating code which creates a single executable in multiple projects can be useful if you want to
Personally, I base most of my decisions on the second point. Do I think that part of the application can be a more general library that I am likely to need in other application? Put it in a separate project. Otherwise, as you point out, having a single project usually makes development easier.
About the circular dependencies: The recommended way to solve this is to put interfaces of the referenced stuff into a third project. For example, if you have two applications both sharing some objects through remoting, you put interfaces of the shared objects in a library project to ensure that they are available to both applications.
Without knowing the exact design of your application, it's difficult to give more concrete advise.