为什么在Visual Studio中有单独的调试和发布文件夹?

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

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

如果您从命令行的外部运行脚本和工具(即围绕它构建某种发布或部署过程),那么最好在构建服务器上执行此操作,因为调试和发布之间的区别将消失。

例如,当从命令行(在生成服务器上)调用msbuild时,可以指定要调试或发布的配置属性,以及要生成到一个位置的outputpath属性(无论配置如何)。

Dave,如果您将编译调试并发布到单个文件夹中,您可能会遇到这样的情况:在从版本切换到调试之后,某些DLL-S将不会重新编译,反之亦然,因为DLL文件将比源文件更新。是的,“重建”应该对您有所帮助,但是如果您忘记了这一点,您可以有几个额外的调试时间。

我使用不同文件夹的一个原因是它保证我只生成使用版本构建代码的安装程序。我使用wix,它允许我指定要包含在安装程序中的文件的确切路径,所以我最终指定了release文件夹中的路径。(当然,使用普通的vs安装程序也可以这样做,所以这不是重点。)如果您忘记在构建之前将项目切换到发布,安装程序不会构建,除非您在发布文件夹中有旧代码,在这种情况下,您最终会得到一个旧的安装程序,所以这有点陷阱。我解决这个问题的方法是在WIX安装程序项目上使用后期生成事件,在WIX安装程序生成之后清除发布文件夹。

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

mainprogram.exe库.dll

成为

mainprogramd.exe&libraryd.dll文件

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

显然,您需要更改所有引用,以指向用于调试的修改后的名称——在某个时刻您将忘记这样做。

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

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

另一方面,我不明白开发人员为什么要使用发布版本(来回切换)-发布模式只对完整/近似的构建有用,因此VS中的解决方案在默认情况下可以保持在调试模式,而构建脚本(无论如何)总是执行干净的发布构建。

有时,可能会遇到一个特别严重的未初始化内存问题,该问题只在发布版本中发生。如果您无法维护(如Chrisf建议的那样)调试和发布二进制文件的独立名称,那么很容易就无法跟踪当前使用的二进制文件。

此外,您可能会发现自己在调整编译器设置(即优化级别、使用调试符号发布以便于分析等),并且使用单独的文件夹更容易保持这些设置的顺序。

不过,这都是个人喜好的问题——这就是为什么Visual Studio可以轻松地更改选项。

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

开发人员会问你,你喜欢谁?

在VC++中,我们生成了不同的库,您需要链接适当的版本。否则将出现链接器错误。

在你的集会中保持一致是件好事。您不想处理与条件编译/etc有关的问题,在这些问题中,您的发布和调试DLL不兼容,但您试图对彼此运行它们。

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

而且不要忘记人的方面:如果两个构建输出到不同的位置,那么就更容易知道您正在使用什么(并修复损坏的构建)。