40

I've seen a lot of different takes on this subject so I figured if there's a preferred way on this.

Is there any best practices on how to setup Visual Studio Projects and Solutions in regards to multiple solutions for the same solutions?

For example: Let's say I have a task that calls for a web app, a console application, and a shared business logic library.

I have seen this situation in a 1, 2, and 3 solutions at some time in my career. This is a simple example; however, what if number of projects grows? Is there a line when to keep it in one or break it apart?

JamesEggers
  • 12,885
  • 14
  • 59
  • 86

6 Answers6

16

Indeed, there are some guidelines for this sort of setup on MSDN. I wrote a short summary in my answer to a similar question on StackOverflow.

Community
  • 1
  • 1
Greg D
  • 43,259
  • 14
  • 84
  • 117
15

I blogged about this back in 2007. The advice still holds:

http://mikehadlow.blogspot.com/2007/07/how-to-structure-visual-studio.html

The bottom line is that I should be able to get your code out of source control, open it in Visual Studio, hit F5 and everything should work.

Mike Hadlow
  • 9,427
  • 4
  • 45
  • 37
  • Thanks for writing that; I found it helpful, especially this: "Ideally, all the source your team writes should be in a single solution file with all the projects referenced with project references. Not doing this is the single biggest source of solution problems I’ve seen. Never use file references for internal assemblies! It’s such a headache" – Jon Coombs Feb 23 '14 at 03:00
  • This seems to assume a 1:1 ratio between teams and applications. I have a hard time accepting that separate applications should be grouped together inside the same solution just because they are developed by a single team. When applications have projects in common, yes, but otherwise, no. – Christian Davén Feb 14 '23 at 13:01
7

Solutions are for the developer, in a particular situation. Projects (.CSPROJ for C-Sharp) are where the real compilation takes place.

Theoretically if there are 4 different projects, there could be 24 different combinations of those projects a developer may want to combine into solutions.

If you keep everything at a project level, you won't need to worry about how a developer has arranged their .SLN files

Brad Bruce
  • 7,638
  • 3
  • 39
  • 60
  • 4
    I asked a Microsoft 'expert' at TechEd this year and he basically concurred with waht you say here in that he advocated not adding .sln files to source control at all, only .csproj files. Each developer chooses what combinations are appropriate for a particular task. – rohancragg Dec 18 '08 at 14:43
  • 6
    That's helpful to consider, but it seems odd to me. Surely if multiple developers are working on a single Windows Forms application, they're going to want to build it in the same way. And you could always have multiple .sln files in source control, I would think. – Jon Coombs Feb 23 '14 at 02:58
4

You can have multipe solutions, and each one can reference the projects that it cares about. Extending your example, your shared business logic library may have a corresponding unit test library. These two projects can be contained in one solution. At the same time, you may have another solution that contains the three projects that you mention, but in this case the unit test library isn't included.

PJ8
  • 1,278
  • 10
  • 15
4

My solutions typically consist of:

  • Web Application project
    • 'Common' folder for base & common helper classes
    • 'Include' folder
      • 'Styles' folder
      • 'Scripts' folder
      • 'Images' folder
    • 'UserControls' folder
  • Web Services project
  • Web Framework project
  • Business Tier project
  • Business Framework project
  • Data Access project
Kon
  • 27,113
  • 11
  • 60
  • 86
1

I like to include all projects for a certain task, in a solution. So based on the example you mention, I would have a solution containing the three projects that belong to the solution I was asked to do. That keeps all elements to complete a task together, I find this simplifies the inclusion of other elements required to solve the task at hand.

CheGueVerra
  • 7,849
  • 4
  • 37
  • 49