This is really a tale of two customers – both reasonably large and successful companies who’ve been using VS for many years. Both had reached out to us with saying they were having problems with sluggishness and stability when dealing with solution files containing 100s of projects and millions of files. One customer, for example, had a solution file with 500 projects (all .NET), which was making VS hang and crash from anywhere within five to 60 minutes of opening a solution. Another customer had a solution file with 200 projects (mostly .NET, but a handful of C++ projects). Though this project would load successfully, it would consuming a lot of CPU cycles, causing the IDE to be very sluggish while editing code, and the customer also experienced random crashes. On the surface, these might look like very related issues. But they weren’t. As we talked with the customers and debugged their solutions, it became clear that the root causes were pretty different.
the root cause is actually the same. it's always the same. it's in the DNA. I know people who would put hundreds of projects together in a single solution and people who wouldn't. these are different kinds of people ‎- Freedom Enforcement Officer
I wonder why it might not be natural to add all related projects to a solution, except for the experimental knowledge that it makes things slow. There's no reason it should not work, given that VS team considered it, used a proper database, messaging, scope limiting, caching, etc — if it makes sense for real customers. OTOH I wonder what kind of tight coupling 500 projects may have to need to be in the same solution. ‎- 9000
^ it is a grand unified solution for everything, obviously ‎- plain