默认情况下，Visual Studio为Debug和Release构建分别创建了单独的bin文件夹。从处理外部依赖的角度来看，我们有一些小问题，有时我们需要发布二进制文件，有时需要debug版本。如果所有项目都使用单个bin文件夹作为调试和发布目标，则可以使生活稍微轻松一些。然后，我们可以将外部脚本等指向单个位置。
一位同事问我们为什么不能这样做 - 更改VS项目设置以进入同一个bin文件夹？我承认，除了能够轻松地查看我的本地文件系统上的Debug和Release版本之外，我真的想不出保留它们的好理由是什么。但那又怎样？这有什么好处呢？
我的问题：
我并不是在问为什么要有单独的Debug和Release版本。我理解它们的区别及其各自的用途。我的问题涉及将它们放置在单独的文件夹中。
如果你将Debug和Release编译到一个单独的文件夹中，可能会遇到这样的情况：在从Release切换到Debug或从Debug切换到Release时，某些dll文件不会被重新编译，因为它们比源文件更新。是的，“Rebuild”应该能帮助你解决这个问题，但如果你忘记了这一点，就可能需要额外花费几个小时进行调试。
我使用单独的文件夹的一个原因是确保我只生成使用Release-build代码的安装程序。我使用WiX，它允许我指定要包含在安装程序中的文件的确切路径，因此我最终会在Release文件夹中指定路径。(当然，您也可以使用普通的VS安装程序完成相同的操作，所以这并不是重点。)如果您在构建之前忘记将项目切换到Release，那么除非您在Release文件夹中有旧代码，否则安装程序不会构建，这是一个小问题。我解决这个问题的方法是在WiX安装程序项目上使用后期构建事件清除release文件夹。
变成了MainProgram.exe & library.dll
这意味着它们可以共存于同一输出文件夹中，所有脚本、路径等都可以直接引用它们。但是中间文件仍然需要放在单独的文件夹中，因为这些文件的名称不能更改。MainProgramD.exe & libraryD.dll
我通常在Debug模式下编译，但有时需要在Release模式下编译。不幸的是，在某些错误情况下，它们的行为并不完全相同。通过拥有单独的文件夹，我无需重新编译所有东西就可以更改模式（在Release模式下对我们的所有内容进行完整重新编译需要一段时间）。
我有从一个比较大的项目中获得的经验。如果有几个解决方案使用文件引用到其他解决方案，你需要将引用指向一个目录，显然这必须是连续/夜间构建的“发布”目录。现在你可以想象一下，如果开发人员想要使用调试版本会发生什么 - 所有的引用都指向发布版本。如果它指向同一个目录，切换到调试模式只需要重新编译所有相关的东西以调试模式进行，文件引用会自动指向调试版本。
另一方面，我不明白为什么开发人员会想要使用发布版本（并来回切换） - 发布模式只对全量/夜间构建有用，所以VS中的解决方案默认保持在调试模式，而构建脚本（无论如何）总是执行干净的发布构建。
在你的程序集中保持一致是一件好事。你不想处理条件编译等问题，其中你的发布和调试dll不兼容，但你正在尝试相互运行它们。
关于技术方面，大家说的都很重要。另一个方面是，如果一个构建依赖于单一输出位置构建，但两个构建之间没有同步，那么您可能会遇到竞争条件。如果第一个构建可以在第二个构建开始后重新运行（特别是在不同的模式下），您将无法确定是否使用了调试或发布构建。
不要忘记人的因素：如果两个构建输出到不同的位置，那么更容易知道您正在处理什么（并修复损坏的构建）。
Visual Studio等IDE适合大众使用。它们创建默认的项目结构和二进制文件夹。您可以将这些二进制文件映射到单个文件夹中。然后，您需要告知其他开发人员Release/Debug文件存储在同一文件夹中。
开发人员会问您，为什么要这样做？
在VC++中，我们生成不同的库，您需要链接适当的版本。否则，您将收到链接器错误。
