为什么在 Visual Studio 中有单独的 Debug 和 Release 文件夹？答案

【问题标题】：Why have separate Debug and Release folders in Visual Studio?为什么在 Visual Studio 中有单独的 Debug 和 Release 文件夹？
【发布时间】：2011-01-04 05:23:32
【问题描述】：

当然，默认情况下，Visual Studio 会为调试和发布版本创建单独的 bin 文件夹。从外部依赖的角度来看，我们在处理这些问题时遇到了一些小问题，有时我们需要发布二进制文件，有时需要调试。在所有项目上只使用一个 bin 文件夹并使其成为 Debug 和 Release 的目标会使生活稍微更容易。然后我们可以将我们的外部脚本等指向一个位置。

一位同事质疑为什么我们不能这样做——更改 VS 项目设置以转到同一个 bin 文件夹？我承认我真的想不出一个很好的理由来保留它们，除了很容易在我的本地文件系统上看到哪些是 Debug 和哪些是 Release。但那又怎样；这有什么好处？

我的问题：

如何利用不同的 Debug 和 Release 文件夹？这在您的开发中启用了哪些流程？
如果不保留这种区别会发生什么坏事？
反之，如果您走的是“单一文件夹”路线，这对您有何帮助？

我不是在问为什么有单独的调试和发布版本。我理解它们的区别，以及它们各自的位置。我的问题涉及将它们放在单独的文件夹中。

【问题讨论】：

您应该在项目中设置构建后步骤，以将文件复制到 ebinaries 目录。

标签： visual-studio debugging release

【解决方案1】：

Dave，如果你将 Debug 和 Release 编译到单个文件夹，你可能会遇到一些 dll-s 在从 Release 切换到 Debug 后不会重新编译的情况，反之亦然，因为 dll 文件会比源文件更新。是的，“重建”应该对您有所帮助，但如果您忘记了这一点 - 您可以多花几个小时进行调试。

【讨论】：

没错。使用相同的文件夹可能会导致您构建二进制文件的情况，其中一半的源代码来自 Debug 版本，一半来自 Release 版本。调试绝对不是一个有趣的情况。

【解决方案2】：

在我看来，这只是开发人员机器上的一种便利，允许他们同时编译和运行调试和发布版本。

如果您在 Visual Studio 中运行脚本或工具，IDE 允许您使用 ConfigurationName 和其他宏来获取与配置无关的路径。

如果您从命令行外部运行脚本和工具（即您正在围绕它构建某种发布或部署过程），最好在构建服务器上执行此操作，其中调试和发布之间的区别消失了。

例如，当您从命令行（在构建服务器上）调用 msbuild 时，您可以为 Debug 或 Release 指定 Configuration 属性，并将 OutputPath 属性指定为仅构建到一个位置（与 Configuration 无关）。

【讨论】：

【解决方案3】：

我使用单独文件夹的一个原因是它保证我只生成使用发布构建代码的安装程序。我使用 WiX，它允许我指定要包含在安装程序中的文件的确切路径，因此我最终指定了 Release 文件夹中的路径。（当然，您可以使用普通的 VS 安装程序执行相同的操作，所以这不是重点。）如果您忘记在构建之前将项目切换到 Release，除非您在 Release 中有旧代码，否则安装程序不会构建文件夹，在这种情况下，你最终会得到一个旧的安装程序，所以这有点陷阱。我解决这个问题的方法是在 WiX 安装程序项目上使用构建后事件，在 WiX 安装程序构建后清除发布文件夹。

【讨论】：

我更喜欢使用带有“发布”目标的构建脚本来为我进行发布构建。这样我什至不必考虑在什么构建配置 VS，我只需运行发布命令，然后坐下来喝我的咖啡 :)
完全同意，WiX+msbuild+CI 工具可以让构建顺利，咖啡更顺畅！

【解决方案4】：

在以前的公司中，我们通过更改调试可执行文件的名称和附加“D”的 dll 来解决这个问题。所以

MainProgram.exe & library.dll

成为

MainProgramD.exe & libraryD.dll

这意味着它们可以共存于同一个输出文件夹中，并且所有脚本、路径等都可以引用它。中间文件仍然需要转到单独的文件夹，因为它们的名称不能更改。

显然，您需要更改所有引用以指向修改后的名称以进行调试 - 您有时会忘记这样做。

【讨论】：

我也将它用于 dll，我所有的 dll 都进入系统路径中的一个目录。

【解决方案5】：

我通常在Debug模式下编译，但有时需要在Release模式下编译。不幸的是，它们在某些错误情况下的行为并不完全相同。通过拥有单独的文件夹，我不需要为了更改模式而重新编译所有内容（并且在发布模式下完全重新编译我们的东西需要一段时间）。

【讨论】：

【解决方案6】：

我有一个更大的项目的经验。如果很少有解决方案使用对其他解决方案的文件引用，则必须将引用指向 ONE 目录，因此显然它必须是连续/夜间构建的“发布”目录。现在您可以想象如果开发人员想要使用调试版本会发生什么——所有引用都指向发布版本。如果它指向同一个目录，切换到调试只需要在调试模式下重新编译所有相关的东西，文件引用将自动指向调试版本。

另一方面，我不明白为什么开发人员会想要使用发布版本（以及来回切换） - 发布模式仅对完整/夜间构建有用，因此 VS 中的解决方案默认情况下可以保持调试模式，并且构建脚本（无论如何）总是干净，发布构建。

【讨论】：

【解决方案7】：

有时可能会遇到特别讨厌的未初始化内存问题，该问题仅在发布版本中发生。如果您无法（如 ChrisF 建议的那样）为您的调试和发布二进制文件维护单独的名称，那么很容易丢失您当前正在使用的二进制文件。

此外，您可能会发现自己正在调整编译器设置（即优化级别、用于轻松分析的发布带调试符号等），并且使用单独的文件夹保持这些设置更容易。

不过，这完全取决于个人喜好 - 这就是 Visual Studio 可以轻松更改选项的原因。

【讨论】：

【解决方案8】：

Visual Studio 类型的 IDE 最适合人群。他们创建默认的项目结构，二进制文件夹。您可以将二进制文件映射到单个文件夹。然后您需要告知其他开发人员 Release/Debug 文件存储在同一文件夹中。

开发者会问你，你喜欢谁？

在 VC++ 中，我们生成了不同的库，您需要链接相应的版本。否则你会得到链接器错误。

【讨论】：

【解决方案9】：

在您的程序集中保持一致是一件好事。您不想处理有关条件编译/等的问题。您的发布和调试 dll 不兼容，但您正在尝试相互运行它们。

【讨论】：

【解决方案10】：

其他人对技术方面的看法很重要。另一方面是，如果一个构建依赖于单输出位置构建，那么您可能会遇到竞争条件，但两个构建之间没有同步。如果第一个构建可以在第二个构建开始后重新运行（尤其是在不同的模式下），那么您将不会真正知道您是否正在使用发布构建的调试。

并且不要忘记人的方面：如果两个构建输出到不同的位置，则更容易知道您正在使用什么（并修复损坏的构建）。

【讨论】：