title: What is the best practice for "Copy Local" and with project references?
body: <p>I have a large c# solution file (~100 projects), and I am trying to improve build times.  I think that "Copy Local" is wasteful in many cases for us, but I am wondering about best practices.</p>
  
  <p>In our .sln, we have application A depending on assembly B which depends on assembly C.  In our case, there are dozens of "B" and a handful of "C".  Since these are all included in the .sln, we're using project references.  All assemblies currently build into $(SolutionDir)/Debug (or Release).</p>
  
  <p>By default, Visual Studio marks these project references as "Copy Local", which results in    every "C" being copied into $(SolutionDir)/Debug once for every "B" that builds.  This seems wasteful.  What can go wrong if I just turn "Copy Local" off?  What do other people with large systems do?</p>
  
  <p>FOLLOWUP:</p>
  
  <p>Lots of responses suggest breaking up the build into smaller .sln files...  In the example above, I would build the foundation classes "C" first, followed by the bulk of the modules "B", and then a few applications, "A".  In this model, I need to have non-project references to C from B.  The problem I run into there is that "Debug" or "Release" gets baked into the hint path and I wind up building my Release builds of "B" against debug builds of "C".  </p>
  
  <p>For those of you that split the build up into multiple .sln files, how do you manage this problem?</p>