Example
I work on project, which have 3 separate parts (ASP.NET MVC, WinForms, Silverlight) and 15 project (Common, Api, Services, Repository and WinForm's CABs).
Resolutions
1) All this project in one solution
2) For each part have solution
What is the best way to deal with Solutions and Projects in Visual Studio?
First is great if I do refactoring.
Second is good for better clarity.
My preference is to create shared projects in some global area and add them into specific application configurations (solutions) where required. Non shared projects, specific to a solution, can live within that solution. Just bear in mind that changes to a shared project in one solution will affect that project in any other solutions that use it.
Naturally is one solution per application (exe or hosted doesn't matter). Then put all assemblies that you often debug or refactor.
Other keep as compiled binaries.
I would have one solution for each part, meaning that each ASP.NET MVC, silverlights and winform has their own .sln file.
As far as refactoring goes, it shouldn't matter because if you have Resharper installed, the moment you refactor the code in other solutions, your un-updated csprojects' cs files will be beaming with red color ( without compilation), and you can just rename at one click ( Change all xxx to yyy option)
My preference is to have just one solution file and then create solution folders under each (Services, Common, Presentation, etc).
Then, under the Presentation folder create separate folders for Web, Windows, Silverlight. Each project would be placed in the appropriate folder.
To me, this is the simplest approach to keep everything under one roof. Easier to compile, share resources, and manage source control.
So, a typical solution for me could have 15 - 20 different projects in the tree, depending on the complexity of the solution.
I would actually think that the first would be better for clarity. The reason being that it's easier to tell if you change a shared project for MVC if the compiler yells at you for the WinForm project. Plus you should be able to set the debugger up so that when you click Debug it will only debug the selected project (select the MVC, WinForm or Silverlight before clicking the debug button). This makes it easier for you to debug MVC, Winform and Silverlight without needing to change any debug settings.
Depending on the size of the individual projects, I would use a single solution for all the projects. I never put projects inside solution folders, reserve that for shared assemblies, read me files, etc.
I suggest creating an SolutionInfo.cs in the Solution Items folder and add a reference to this within all of your projects. Then you can remove most of the assembly attributes within the AssemblyInfo.cs files. I only have 3 attributes in AssemblyInfo: AssemblyTitle, AssemblyDescription, Guid. The other properties are shared amongst all my projects.
Having all projects in the same solution ensures you have proper namespaces and no collisions between the different client implementations.
Name your projects in accordance with the namespaces, for example if your project is named "Sport", then name the solution "Sport", the shared library for "Sport.Common", "Sport.Web" and so forth.
I only start to consider separating projects in multiple solutions when I have performance issues with compilation taking to much time. Having everything in the same solution makes it much easier to manage, especially if you're using a source control system.