Relation between projects and solutions in VS

Question

We're about to start with a new software and there are mixed opinions on the organization of software. I'd be delighted to hear what others might have to say in regard to the presented options as well as what other consideration one might refer to when making such a decision.

1. Hierarchical approach
2. Interchangeable approach

Approach #1 would consist of a single solution in VS with a number of projects connected to it (such as Utilities, Service, Exporter, Gui etc.). Everything would be in a single collection and the same root directory (for the solution file) and subdirectories (for the project files), so to speak.

Approach #2 would be constituted primarily of a set of projects, not related to each other (other than the references, of course), while the solution's (or solutions', would we desire to create different setups for different deliveries) purpose would be solely to refer to the (external) projects collecting them in the GUI. There would be n+1 directories (one for each project's file and an additional one for the solution's file, or solutions' files later on).

We've discussed the matter and listed the advantages of each approach and, although agreed on the facts, the team's members are not on the same page regarding which one to choose. We're a very democratic organization, so the decision needs to be persuasive to everybody (or at least a vast majority) and there won't be any from-above order from the boss. There's no prior code base and the financial consideration needs not to be addressed.

Which approach is preferable? Which is more of a commonly applied standard in the industry? What considerations might one take to ensure the rigidity of the choice?

It's also fully possible that our current project will be subject to the situation described in this question - both being the one that "borrows" projects from elsewhere as well as being the one that the projects are "borrowed" from.

Answer 1

It depends... its all about dependency management.

You're going to have a lot easier time with a single solution. This is so you can simply reference the other projects within a project and it'll all build and will be up to date everytime. This approach doesn't scale though.

So the problem is entirely down to those pesky references. The biggest problem I found was that the paths to external references (ie not part of the solution) were relative. So your team members must checkout a library in the same position in the build tree as it was originally created. If you can live with this restriction, building individual projects will be viable.

However, today Microsoft is using NuGet as a way to deliver libraries to applications. You build a lib, package it as NuGet and deploy it to a server. Then, when an application wants to use this library, it will automatically fetch it. No more compiling, you can always get the latest version from the build server (you so have CI, if not - get Jenkins. OSS/free and awesome).

This means you can concentrate on your part of the application rather than the dependencies. It also means you'll be more likely to keep a good separation of concerns in these libraries.

Answer 2

I recommend a Single Solution Approach -- especially for the start of a new project. (You can get more complicated later on, iff you need to.)

MS itself has ought to say on that matter:

• Structuring Projects and Solutions v2002
• Structuring Projects and Solutions v2007

My experience is (as MS says):

This structure simplifies development because all of the code is available when you open the solution. This strategy also makes it easy to set up references, because all references are between projects in your solution.

And:

You should use this structure if all developers use the same solution and have the same set of projects. This could be a problem for large systems where you want to organize projects by sub-system or feature.

Multi-Solution Projects are a headache (believe me I am there atm.) and you should only do this if you need to, either because the components are very loosely coupled and must be able to be compiled and combined in isolation or because you have so many projects (I'd say > 100 is a rough estimate) that one single solution becomes unwieldy.

---

Note: Skipping essay on NuGet / package managers / your specific SCC and CI. They all play into this.