visual studio - Structuring projects & dependencies of large winforms applications in C#

Question

UPDATE:
This is one of my most-visited questions, and yet I still haven't really found a satisfactory solution for my project. One idea I read in an answer to another question is to create a tool which can build solutions 'on the fly' for projects that you pick from a list. I have yet to try that though.

---

How do you structure a very large application?

• Multiple smallish projects/assemblies in one big solution?
• A few big projects?
• One solution per project?

And how do you manage dependencies in the case where you don't have one solution. Note: I'm looking for advice based on experience, not answers you found on Google (I can do that myself).

I'm currently working on an application which has upward of 80 dlls, each in its own solution. Managing the dependencies is almost a full time job. There is a custom in-house 'source control' with added functionality for copying dependency dlls all over the place. Seems like a sub-optimum solution to me, but is there a better way? Working on a solution with 80 projects would be pretty rough in practice, I fear.

(Context: winforms, not web)

EDIT: (If you think this is a different question, leave me a comment)

It seems to me that there are interdependencies between:

• Project/Solution structure for an application
• Folder/File structure
• Branch structure for source control (if you use branching)

But I have great difficulty separating these out to consider them individually, if that is even possible.

I have asked another related question here.

Answer 1

Source Control

We have 20 or 30 projects being built into 4 or 5 discrete solutions. We are using Subversion for SCM.

1) We have one tree in SVN containing all the projects organised logically by namespace and project name. There is a .sln at the root that will build them all, but that is not a requirement.

2) For each actual solution we have a new trunks folder in SVN with SVN:External references to all the required projects so that they get updated from their locations under the main tree.

3) In each solution is the .sln file plus a few other required files, plus any code that is unique to that solution and not shared across solutions.

Having many smaller projects is a bit of a pain at times (for example the TortoiseSVN update messages get messy with all those external links) but does have the huge advantage that dependancies are not allowed to be circular, so our UI projects depend on the BO projects but the BO projects cannot reference the UI (and nor should they!).

Architecture We have completely switched over to using MS SCSF and CAB enterprise pattern to manage the way our various projects combine and interact in a Win Forms interface. I am unsure if you have the same problems (multiple modules need to share space in a common forms environment) but if you do then this may well bring some sanity and convention to how you architect and assemble your solutions.

I mention that because SCSF tends to merge BO and UI type functions into the same module, whereas previously we maintained a strict 3 level policy:

FW - Framework code. Code whose function relates to software concerns. BO - Business Objects. Code whose function relates to problem domain concerns. UI - Code which relates to the UI.

In that scenario dependancies are strictly UI -> BO -> FW

We have found that we can maintain that structure even while using SCSF generated modules so all is good in the world :-)