在弄清楚 Blend 4 如何构建 Visual Studio 项目/解决方案时，我发现了为什么我们的图形设计师的 Blend 副本无法正常工作并解决了问题。我们设置的多个构建配置是罪魁祸首。以下是我发现的详细信息以及对使用多种构建配置、Blend 4 和 Visual Studio 2010 的其他人的警告列表。
警告 1：Blend 不允许您选择构建配置。
在 Visual Studio 中，构建时始终使用特定的构建配置进行构建。可以更改此设置。 Blend 似乎无法在其 UI 中的任何位置更改构建配置设置。相反，它使用自己的启发式方法来选择要使用的构建配置。
警告 2：Blend 在构建时选择构建配置的逻辑与在设计时不同。
这就是给我们带来问题的原因。 Blend 似乎有两种不同的方式来选择构建配置。编译时，它使用 .csproj 文件中的逻辑来选择默认构建配置（请参阅警告 3）。然而，设计者会查看解决方案文件，它应该使用哪个构建配置的输出目录来解析程序集引用（请参阅警告 4）。因此，尽管 Blend 编译正常，但设计者并没有查看编译后的文件，而是查看它创建的空 bin 目录。
警告 3：Blend 和 Visual Studio 处理默认构建配置的方式不同。
在 .csproj 文件的顶部，有一个属性组，用于指定在运行 csc.exe 时未指定时要使用的构建配置。 Visual Studio 似乎没有修改这些数据，可能是因为它不需要它，因为它总是使用定义的构建配置。我们已经删除了默认的 Debug 和 Release 配置，并制作了我们自己的 DebugWindows、ReleaseWindows、DebugMac 和 ReleaseMac 配置，但项目文件仍然说在未指定配置时使用“Debug”。 Blend 4 在没有构建配置的情况下运行 csc.exe，因此使用默认逻辑。因此，我不得不手动修复 .csproj 文件。
警告 4：Visual Studio 不允许您对解决方案的构建配置进行排序，并且排序与 Blend 有关。
与 Blend 在编译时选择构建配置的方式相反，Blend 的设计者似乎使用解决方案文件中的第一个解决方案配置来将项目与构建配置相关联。然后，设计器在输出目录中查找其程序集的 that 配置。换句话说，如果 .csproj 构建配置默认值和 first-solution-configuration 的设置不匹配，即使您构建了项目，设计人员也不会看到您的类、合并的资源字典等。
不能通过 Visual Studio 更改首先的解决方案配置。为了解决设计师寻找构建工件的位置，我们必须在 .sln 文件中手动重新排序解决方案配置。