将程序集编译为单独的文件夹有什么意义？在我的工作中，我们有50多个项目，它们存在于几个不同的解决方案中。当项目在同一解决方案中时，您可以设置项目引用，并相应地在\ debug或\ release文件夹中获取程序集。但是，当设置外部引用（通过浏览）并明确指向\ debug \ assebmly.dll或\ release \ assembly.dll时，如果引用的项目是在发布模式下编译的，则引用项目将不会选择“发布”程序集。
我理解通常构建过程可以处理这个问题，但是在我需要在构建过程之外的发布模式下编译项目的情况下，这意味着我必须检查所有外部引用以确保它们指向\ release文件夹。这很容易错过 - 而且我不想每次都要考虑。所以我的想法是始终将项目的程序集编译到\ bin文件夹，无论是选择了调试还是发布配置。这方法有什么缺点吗？
答案 0 :(得分：3)
不仅是二进制文件，它也是中间文件。这就是为什么有必要编译到不同的目录。
如果要将二进制文件放在bin文件夹中，请更改输出文件或添加copy作为自定义生成步骤。我知道这会给您的工作流程带来一些不便，但您必须意识到默认情况下构建到相同的文件夹对于很多人来说都是一个巨大的PITA。
此外，在向解决方案之外的项目添加引用时，请尝试在引用中使用$(ConfigurationName)之类的宏，以根据需要在路径中自动插入“Release”或“Debug”。 （我羡慕你只需处理两个默认配置......）
然后，这是另一个想法：项目可以存在多个解决方案。为您必须构建的每个有效项目组合提供解决方案。这样您就可以使用Project Dependency功能，只需点击一下即可构建最新的解决方案版本。
答案 1 :(得分：3)
嗯，这很简单，因为不使用单独的文件夹会更糟糕。你将构建Release，发现有些不对劲，切换回Debug，不获取程序集的实际Debug版本。除非您先明确使用Build + Clean。现在你要去战斗或者去拜访SO，忘记你为什么要换回来。
处理来自其他解决方案的项目输出也很简单：始终添加对Release版本的引用。因为如果您需要调试和更改该程序集，那么您可以将项目添加到当前解决方案中。
答案 2 :(得分：0)
如果您将所有内容构建到单个文件夹，切换配置，然后执行部分解决方案构建（例如，只是您的数据组件），您可以轻松地使用正在使用的调试和发布程序集的混合。这是一件坏事。
通过将构建保存在单独的文件夹中，可以确保所有程序集都是使用相同的配置构建的。