By default, Visual Studio (2010 as well as 11 beta) builds every project in a solution to a separate folder. As a result, especially if the projects reference each other, they get copied around quite a lot during build (CopyLocal = true):
-- solution has four projects: proj1, proj2, proj3 and proj4
-- building proj1 --
solution/proj1/bin/debug/proj1.dll
-- building proj2 (depends on proj1) --
solution/proj2/bin/debug/proj1.dll
solution/proj2/bin/debug/proj2.dll
-- building proj3 (depends on proj1) --
solution/proj3/bin/debug/proj1.dll
solution/proj3/bin/debug/proj3.dll
-- building proj4 (depends on proj2 and proj3) --
solution/proj4/bin/debug/proj1.dll
solution/proj4/bin/debug/proj2.dll
solution/proj4/bin/debug/proj3.dll
solution/proj4/bin/debug/proj4.dll
Since my current solution has 90 projects, from which the majority have at least a few references to one another (only 3 are actual executables), this is quite annoying and I’ve been wondering why, by default, Visual Studio does not just put every project output in the same folder but instead causes this horrendous redundancy. I am aware that I can change the output folder and turn off the copying of referenced projects, but I’d like to know if there is a reasoning behind the default behavior.
VS2005 does put everything in one folder by default (not sure about 2008), but did that have any actual disadvantages? Also, is there a way in VS10 (VS Addon maybe) to set the output folder for all projects to the same folder, as well as setting CopyLocal = false for each project reference?
One thing I can think of is to separate the projects from each other, that is: if you change (and compile) one project it does not immediately break other projects that have not been updated properly to handle the change.
If everything is in one folder, the above scenario could cause unnecessary headaches (until you rebuild the whole solution).