visual-studio 为什么在 Visual Studio 中有单独的 Debug 和 Release 文件夹？

Why have separate Debug and Release folders in Visual Studio?

提问by Dave Mateer

By default, of course, Visual Studio creates separate bin folders for Debug and Release builds. We are having some minor issues dealing with those from the perspective of external dependencies, where sometimes we want release binaries and sometimes debug. It would make life slightlyeasier to just have a single bin folder on all projects and make that the target for both Debug and Release. We could then point our external scripts, etc. at a single location.

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

A co-worker questioned why we couldn't just do that--change the VS project settings to go to the same bin folder? I confess I couldn't really think of a good reason to keep them, other than easily being able to see on my local filesystem which are Debug and which are Release. But so what; what does that gain?

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

My question(s):

我的问题：

• How do you leverage having distinct Debug and Release folders? What processes does this enable in your development?
• What bad thing could happen if you fail to retain this distinction?
• Inversely, if you have gone the "single folder" route, how has this helped you?

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

I am NOT asking why have separate Debug and Release builds. I understand the difference, and the place of each. My question concerns placing them in separate folders.

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

采纳答案by rikoe

The way I see it, this is simply a convenience on the developer's machine allowing them to compile and run both Debug and Release builds simultaneously.

在我看来，这只是开发人员机器上的一种便利，允许他们同时编译和运行 Debug 和 Release 构建。

If you have scripts or tools running inside Visual Studio, the IDE allows you to use the ConfigurationName and other macros to obtain paths which are configuration-independent.

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

If you are running scripts and tools externally from the command-line (i.e. you are structuring some kind of release or deployment process around it), it is better to do this on a build server, where the distinction between Debug and Release goes away.

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

For example, when you invoke msbuild from the command-line (on the build server) you can specify the Configuration property for Debug or Release, and the OutputPath property to build to one location only (regardless of the Configuration).

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

回答by Andrey Shvydky

Dave, if you will compile Debug and Release to single folder, you may encounter the situation where some dll-s will not be recompiled after switching from Release to Debug and vice versa because dll files will be newer than source files. Yes, the "Rebuild" should help you, but if you forget this - you can have a few extra hours of debugging.

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

回答by Michael Bray

One reason I use separate folders is that it guarantees that I only generate installers that use Release-build code. I use WiX, which allows me to specify the exact path to the files I want to include in the installer, so I end up specifying the path in the Release folder. (Of course, you can do the same using normal VS installers, so that isn't really the point.) If you forget to switch your project to Release before building, the installer doesn't build unless you have old code in the Release folder, in which case you end up with an old installer, so that's a bit of a pitfall. The way I get around that is to use post-build event on the WiX installer project that clears out the release folder after the WiX installer builds.

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

回答by ChrisF

In a previous company we got round this problem by changing the names of the debug executable and dlls by appending a "D". So

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

MainProgram.exe & library.dll

MainProgram.exe & library.dll

become

变得

MainProgramD.exe & libraryD.dll

MainProgramD.exe & libraryD.dll

This meant that they could co-exist in the same output folder and all scripts, paths etc. could just reference that. The intermediate files still need to go to separate folders as the names of these can't be changed.

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

Obviously you need to change all your references to point to the modified name for debug - which you will forget to do at some point.

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

回答by David Thornley

I usually compile in Debug mode, but sometimes need to compile in Release mode. Unfortunately, they don't behave exactly the same in certain error situations. By having separate folders, I don't need to recompile everything just to change modes (and a full recompile of our stuff in Release mode will take a while).

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

回答by Piotr

I have an experience from somewhat bigger project. If there are few solutions using file references to other solutions, you have to point the reference to ONE directory, so obviously it has to be the "release" one for continuous/night build. Now you can imagine what happens if developer wants to work with debug versions - all the references point to release ones. If it pointed to the same directory, switching to debug would be only matter of recompiling all related stuff in debug mode and the file references would automatically point to debug versions since then.

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

On the other side, I don't see the point why developer would ever want to work with release versions (and switching back and forth) - the release mode is only useful for full/nighlty builds, so the solutions in VS can stay by default in debug mode, and build script (anyway) always does clean, release build.

另一方面，我不明白为什么开发人员想要使用发布版本（并来回切换） - 发布模式仅对完整/夜间构建有用，因此 VS 中的解决方案可以保留默认处于调试模式，并且构建脚本（无论如何）始终执行清理、发布构建。

回答by Mike Willekes

Occasionally one may run into a particularly-nasty uninitialized memory problem that only occurs with a release build. If you are unable to maintain (as ChrisF suggests) separate names for your debug vs. release binaries it's really easy to loose track of which binary you're currently using.

有时，人们可能会遇到一个特别讨厌的未初始化内存问题，这种问题只发生在发布版本中。如果您无法为您的调试和发布二进制文件维护（如 ChrisF 建议的那样）单独的名称，则很容易忘记您当前使用的二进制文件。

Additionally, you may find yourself tweaking the compiler settings (i.e. optimization level, release-with-debug symbols for easy profiling, etc.) and it's much easier to keep these in order with separate folders.

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

It's all a matter of personal preference though - which is why Visual Studio makes it easy to change the options.

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

回答by kyoryu

Being consistent in your assemblies is a good thing. You don't want to deal with issues around conditional compilation/etc. where your release and debug dlls are incompatible, but you're trying to run them against each other.

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

回答by atk

What everyone elsesaid about technical aspects are important. Another aspect is that you may run into race conditions if one build relies on the single-output-location build, but there's no synchronization between the two builds. If the first build can be re-run (especially in a different mode) after the second build starts, you won't really know if you're using a debug of release build.

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

And don't forget the human aspect: it's far easier to know what you're working with (and fix broken builds) if the two builds output to different locations.

并且不要忘记人的方面：如果这两个构建输出到不同的位置，那么了解您正在使用的内容（并修复损坏的构建）要容易得多。

回答by atk

Visual Studio kinds of IDEs works what best for the crowd. They create the default project structure, binary folders. You could map the binaries to the single folder. Then you need to educate the other developers that Release/Debug files are stored in the same folder.

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

Developers would ask you, who you do like that?

开发人员会问你，你喜欢谁？

In VC++, we have different libraries generated and you need to link the appropriate versions. Otherwise you will get linker error.

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