title: What is the optimum number of projects in a Visual Studio 2008 solution?
body: <p>What is the optimum number of projects in a Visual Studio 2008 solution?</p>
  
  <p>We have one Visual Studio 2008 solution that is around 50 projects right now.  It will likely continue to grow as the bulk of the projects within the solution consist of plugin assemblies for the main application.</p>
  
  <p>If it seems like "too many projects" in one solution then how would you go about determining which projects should be grouped together in a solution?  Given our example of approximately 50 projects in one solution with the bulk of the projects being plugins and with the number of plugins likely to grow, how should solutions be structured?  Should all of the plugins be placed in their own solution?  How should the organization change when the number of plugins in the plugins solution hits the magic number of "too many"?</p>
  
  <p>We don't have any issues with this many projects in the solution ... it loads quickly, it builds quickly, it uses a reasonable amount of memory, and doesn't cause VS2008 to crash or bump up against any VS2008 bugs.</p>
  
  <p>I've looked for documentation from Microsoft (there doesn't seem to be any) and Google searches yeild recommendations from "every project gets its own solution" to "place all projects in a single solution."  Both extremes seem to be absurd.  I'm looking for some reasonable guidance in the middle.</p>
  
  <p>There have been other questions on Stackoverflow related to the <a href="https://stackoverflow.com/questions/18871/what-is-the-biggest-vs-solution-youve-ever-seen">maximum</a> you've seen.  That's not quite the same as what the optimum would be.</p>