Recently, we migrated nearly all the source code in my company into a single solution.
Why?
Originally, we had dozens of solutions. Some projects from a solution reused projects from another one, and nobody cared about using a package manager. The day you substantially change a project which is used nearly everywhere, expect hours and hours of lost work for the entire company for the next days or weeks. The worst part is that you can't even know what exactly would be affected by the change.
Merging all the code into one solution was an alternative. It works well for the moment, and the dependencies are now easy to follow. Want to modify a method but also track the repercussions this change may have anywhere in the code base? Visual Studio can do that with ease. For me, it's a success.
Continuous integration is now easier too. One solution to compile and to deploy. Nearly nothing to configure.
Is it scalable?
Performance-wise, I was very surprised by Visual Studio. I thought that it will start crying with a solution with, say, 50 projects. Today, there are more than 200 projects; Visual Studio appeared to be scalable enough to manage them as if there were only 20 of them. Yes, there are things which take time. If you recompile every project, with Code contracts, Code analysis enabled by default, etc., expect it to take a while. But nobody would expect to compile 200 projects as fast as 10, and by the way, you shouldn't: this is the role of the Continuous integration server. Startup time (cold start, then loading the solution) is impressively fast; maybe not as fast as with 10 projects, but still very acceptable (under 20 seconds on a machine bought more than five years ago).
To go even further, systematically unloading projects is a good idea (and really easy when projects are organized in directories within the solution). If somebody works on something which requires only three projects to be loaded, there is no need to load all the 200 projects (unless, of course, dependencies may be affected).
Version control works as expected as well (I'm using an SVN server, if it matters). I haven't worked in a real concurrent environment, with, say, dozens of developers frequently committing code, but I would imagine that this wouldn't have too many issues. Just beware of the cases where many developers add new projects at the same time: merging the .sln file is not the easiest thing to do.
Conclusion
If I had to pick the decision again:
I would still migrate everything into a single solution. This reduces enormously the pain of broken dependencies, and this benefit alone is totally worth it. Having a centralized place for all the code is also a good idea; this makes it possible, for example, to search for something within Visual Studio. I can also work on two weakly-related projects, and still have just one Visual Studio window opened.
I would also study a bit more NuGet and the ability to host a private NuGet server. Managing the dependencies through NuGet can solve some of the problems when you don't want to merge a few projects into the common solution. Personally, I didn't have such cases, but I imagine that other companies might have.
Finally, investing in an SSD for every developer can make a huge difference. But you don't need to, and in my case, the code base is still stored on an ordinary hard drive.
