Changing Visual Studio's default build output path

Are there any good re开发者_C百科asons to modify your project's build output path from its default of "bin\debug"? Is there any benefit to pointing all your projects within a solution to a common build output location?

---

Yes, I typically do this all the time. As Harry said, it reduces disk space usage. That really is not a big deal to me, since disk space is incredibly cheap, but it might be a concern for you. The real reason I do it it to better mirror what the deployment will look like. The best way to do this is to have a property sheet which modifies the output directory to $(SolutionDir)/build/bin. After this, I set the working directory to $(SolutionDir)/build, which is the whole structure which is identical to what would be deployed, rather than having it spread out among the various project directories.

build
|-- bin
|   |-- foo.exe
|   |-- libfoo.dll
|   `-- libbar.dll
|-- plugins
|   |-- extender.py
|   `-- something.lua
`-- skins
    |-- default.skin
    `-- white-and-gold.skin

Overall, having an isolated directory for things that are built (rather than sources) is a good thing. It eases writing custom build steps, since you know where the ultimate output will be and eases integration with your version control system, since you can just set it to ignore that whole directory, rather than going around setting ignore for all .exe, .lib, .so, .dll and whatever for every little directory.

---

The primary reason I change my output directory is to cut down on the number of duplicate assemblies and the number of file copies Visual Studio has to make. If project A references project B, and project C references project A and B then Studio has to build A, copy A to B and build B, then copy A and B to C and build C. You now have 3 copies of assembly A, two copies of assembly B, and one of C. Pointing the output to a single directory, Visual Studio simply builds A, then B, then C. One copy of each. You can imagine how much more disk space and time is consumed for a build as the number of projects and complexity of dependencies grows.

---

As an example I have an updater.exe that is supposed to be distributed with an "other" program. So I set the build path to the "other" programs build path. That way I know i allways have the latest "updater.exe" where it should be.

Thats just one reason.