views:

1506

answers:

5

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?

+1  A: 

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
I suppose best pratice, depends on what you find the most simple to do
CheGueVerra
+2  A: 

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  A: 

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
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
+4  A: 

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.

Greg D
A: 

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