概括
我在使用 Visual Studio 2010 时遇到了一个非常奇怪的行为，我不确定这是否是一个错误，或者是否存在一些扭曲的逻辑来解释为什么它会以这种方式运行。
执行摘要是，当我使用 Batch Build->Select All->Rebuild 为我的所有项目构建所有配置时，VS2010 根据当前选择的解决方案配置生成不同的输出二进制文件。这真的很烦人，因为某些项目输出无法正确运行（在启动时给出“[项目名称]已停止工作”错误对话框），具体取决于在批量构建期间选择了哪个解决方案配置。
更多细节
我有一个包含 3 个 C# 项目的解决方案（1 个 .dll 输出项目，由其他 2 个 .exe 输出项目引用）。在 .exe 输出项目中，项目 A具有Release和Debug项目配置。项目 B具有Debug、Release-x86和Release-x64配置，因为它需要运行一些不同的构建后脚本才能为其提供正确的版本 3rd 方库。
我有 4 个解决方案配置：Debug、Release、Release-x86和Release-x64. Release-x86并-x64设置为仅构建项目 B。Release并Debug构建项目 A 和共享 dll 项目。
如果我Debug从当前配置下拉框中选择解决方案配置，并且全部批量构建，那么当我尝试运行项目 A 的发布配置时，它无法运行。如果我从下拉列表中选择任何其他解决方案配置，然后全部批量构建，则它会成功运行。当我比较生成的 .exe 文件时，我可以看到这两种情况有所不同。
问题
这是 VS2010 的一些已知预期行为吗？如果是这样，有人可以提示为什么会出现这个问题以及如何解决它？这是VS2010中的错误吗？
后续线索？[编辑]
这可能与VS2010如何处理“项目引用”有关吗？正如我所提到的，两个 .exe 项目都引用了 dll 项目，称之为Project D。我通过选择添加引用 -> 项目 -> 项目 D 添加了该引用（例如，对项目 A）。但当然，项目 A 的不同配置想要使用项目 D 的不同配置版本。当我检查项目 A ->属性下的项目 D 引用，我看到一个不可编辑的路径字段。根据选择的解决方案配置，我看到...\Project D\bin\Release\Project D.dll或``...\Project D\bin\Debug\Project D.dll，而且我看不出有任何方法可以控制这一点，所以我猜 VS2010 正试图聪明地选择项目配置的细节。但更奇怪的是，如果我选择 Batch Build -> Select All -> Clean 来删除所有已编译的文件，那么这些引用路径将更改为...\obj\...而不是...\bin\...在我检查它们时，并且我似乎无法将它们改回来，除非删除和重新添加项目引用。
后续 2 [Edit2]
我之前撒了一点谎，我实际上有 2 个 .dll 项目（比如项目 D 和 E），其中 D 通过项目引用引用 E。
我很确定 VS2010 中的项目引用有问题或奇怪的东西是罪魁祸首，我认为我已经找到了选择解决方案配置相关行为的根本原因，步骤如下
1) I Batch Build -> Select All -> Clean，删除所有以前编译的二进制文件。
2) 我从下拉列表中选择一个调试解决方案配置。
3）我批量构建->仅选择项目A发布->重建。
通过查看输出窗口，我看到 VS2010 知道项目 A 依赖于 D，而 D 依赖于 E，因此它会尝试以相反的顺序构建它们。它成功构建了项目 E 的 Release 配置。但是它尝试构建项目 D 的 Release 配置但失败，因为它抱怨缺少 E dll 文件的缺失调试版本。同样，由于缺少 D 的 Debug 版本，A 无法构建。
因此，选择解决方案配置似乎覆盖了项目到项目引用中引用项目的配置。
应该是这样吗？？？