有没有充分的理由从默认的“bin \ debug”修改项目的构建输出路径？将所有项目指向公共构建输出位置的解决方案有什么好处吗？
答案 0 :(得分：10)
是的，我通常会一直这样做 。正如哈利所说，它减少了磁盘空间的使用。这对我来说真的不是什么大不了的事，因为磁盘空间非常便宜，但它可能会让你担心。我这样做的真正原因是为了更好地反映部署的外观。执行此操作的最佳方法是使用property sheet将输出目录修改为$(SolutionDir)/build/bin。在此之后，我将工作目录设置为$(SolutionDir)/build，这是与部署完全相同的整个结构，而不是将其分散到各个项目目录中。
build
|-- bin
| |-- foo.exe
| |-- libfoo.dll
| `-- libbar.dll
|-- plugins
| |-- extender.py
| `-- something.lua
`-- skins
|-- default.skin
`-- white-and-gold.skin
总的来说，为构建的东西（而不是源代码）创建一个孤立的目录是一件好事。它简化了编写自定义构建步骤，因为您知道最终输出的位置并简化与版本控制系统的集成，因为您可以将其设置为忽略整个目录，而不是为所有{设置ignore设置{ {1}}，.exe，.lib，.so以及每个小目录的内容。
答案 1 :(得分：2)
我更改输出目录的主要原因是减少重复程序集的数量和Visual Studio必须创建的文件副本数。如果项目A引用项目B，项目C引用项目A和B，则Studio必须构建A，将A复制到B并构建B，然后将A和B复制到C并构建C.现在有3个程序集A副本，程序集B的两个副本，以及C中的一个副本。将输出指向单个目录，Visual Studio只是构建A，然后是B，然后是C.每个副本。您可以想象，随着项目数量和依赖项复杂性的增加，构建所消耗的磁盘空间和时间会有多少。
答案 2 :(得分：0)
作为一个例子，我有一个updater.exe，应该与“其他”程序一起分发。所以我将构建路径设置为“其他”程序构建路径。这样我知道我总是有最新的“updater.exe”它应该在哪里。
这只是一个原因。