2

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.

Community
  • 1
Konrad Viltersten
  • 205
  • 1
  • 13
  • how many projects do you expect to have? – devnull Jul 23 '14 at 08:11
  • @devnull There will be 6, maybe 8 projects in the solution. There will be only one solution but there **might** be another one or two in the future reusing some of the said projects (and adding new ones). – Konrad Viltersten Jul 23 '14 at 09:01
  • as gbjbaanb already pointed out, having a single solution makes things significantly easier, especially when debugging. it starts becoming an issue when you have more than 40-50 projects per solution, as VS begins to underperform. having multiple solutions is only viable when you have a huge system with clear module separation across different teams. – devnull Jul 23 '14 at 11:28

2 Answers2

6

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.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • We're using TeamCity for CI. However, while NuGet sounds interesting (we've been on that subject during internal discussions), I feel we lack the competence to set up a distribution system of such packages. And even the best technology/approach is bound to fail when used ignorantly. I'm torn between me - the idealist and me - the pragmatist on this one. – Konrad Viltersten Jul 23 '14 at 09:06
  • Did you look at nuget? It's quite simple to create packages, you can even create your packages directly from the .csproj. Certainly a better way than some custom, homegrown solution to dependency management. – Wilbert Jul 23 '14 at 09:55
  • I agree NuGet is a "cool new thing", and I am always distrustful of Microsoft "cool new" things, but in this case it appears to be a solution to dependency management (if over-engineered). You can home-grow your own by simply copying dlls into a common directory in a post-build step. – gbjbaanb Jul 23 '14 at 10:11
  • @Wilbert Perhaps I'm overcomplicating the issue. When you explain it, it appears so simple. But we need some server to manage the package storage and retrieval, don't we? Or am I mistaken here (which I'll gladly be because that'd be awesome in multiple aspects). – Konrad Viltersten Jul 23 '14 at 11:57
  • In the simplest case, you can use a directory on a shared network drive as your 'server'. There's also code available so you can set up your own server in 30 mins or so. [See here](http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds) for more information on your options. – Wilbert Jul 23 '14 at 12:18
1

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:

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.

Martin Ba
  • 7,578
  • 7
  • 34
  • 56