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?
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.
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.
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.
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.
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
My solutions typically consist of: