.net Visual Studio 2008/2010中调试/发布配置编译到不同文件夹的目的是什么？

将程序集编译到单独的文件夹有什么意义？在我的工作中，我们有50多个项目，跨越了几个不同的解决方案。当项目位于同一解决方案中时，可以设置项目引用，并相应地在\debug或\release文件夹中拾取程序集。但是，当设置外部引用（通过浏览）并显式指向\debug\assebmly.dll或\release\assembly.dll时，如果引用的项目是在发布模式下编译的，则引用项目将不会拾取“release”程序集

我知道通常构建过程可以处理这个问题，但如果我需要在构建过程之外以发布模式编译项目，这意味着我必须检查所有外部引用，以确保它们指向\release文件夹。这是很容易错过的事情——我不想每次都去想。因此，我的想法是无论选择了调试配置还是发布配置，都要将项目的程序集编译到\bin文件夹中。这种方法有什么缺点吗

---

不仅是二进制文件，还有中间文件。这就是为什么有必要编译到不同的目录

如果要将二进制文件保存在bin文件夹中，则更改输出文件或添加一个

副本

，作为自定义生成步骤。我知道这会给您的工作流程带来一些不便，但您必须意识到，默认情况下，构建到相同的文件夹对很多人来说都是一个巨大的难题

此外，在向解决方案之外的项目添加引用时，请尝试在引用中使用诸如

$（ConfigurationName）

之类的宏，以便根据需要在路径中自动插入“Release”或“Debug”。（我羡慕您只需要处理两个默认配置…）

---

然后，这里还有另一个想法：项目可以存在于多个解决方案中。为您必须构建的每个有效项目组合提供一个解决方案。通过这种方式，您可以减少对项目依赖性功能的使用，并且只需单击一次即可创建解决方案的最新版本。

这很简单，因为不使用单独的文件夹更糟糕。您将构建一个发布版，发现有什么地方不对劲，切换回调试，而不获取程序集的实际调试版本。除非首先明确使用Build+Clean。现在你要去打剑或参观，忘记你为什么要回去

---

处理另一个解决方案的项目输出也很简单：始终添加对发布版本的引用。因为如果您需要调试和修改该程序集，那么您就已经将该项目添加到了当前的解决方案中。

如果您将所有内容构建到单个文件夹中，则切换配置，然后执行部分解决方案构建（例如，仅构建数据组件），您可以很容易地混合使用调试程序集和发布程序集。那是件坏事

---

通过将生成保存在单独的文件夹中，您可以确保所有程序集都是从相同的配置生成的。

什么是“中间文件”？但是obj文件夹中的文件位于根项目文件夹级别，而调试和发布文件夹位于bin文件夹中。。。所以我不确定我是否理解你所说的中间文件也会受到影响的意思。你能澄清一下吗？嗯，不是我的项目。正如Hans所写，如果要将不同的配置构建到相同的文件夹中，则需要从头开始清理和重建每个配置。如果您的项目具有更多配置，然后是调试和发布，而其他项目依赖于不同的配置，那么不使用单独的文件夹就不可能构建整个解决方案。我理解，我的观点是调试和发布的默认配置，将程序集和vshost文件编译到单独的\bin\debug\和bin\release\文件夹时，obj文件夹位于项目文件夹的根目录下，因此似乎在两个默认配置之间共享。默认情况下，它们应构建为单独的文件夹。