【发布时间】：2010-10-11 15:40:18
【问题描述】：
如果我们有一些开发人员在 64 位机器上工作，而一些开发人员在 32 位机器上工作，但我们需要引用非托管程序集，这些程序集需要为一半团队使用 x86，另一半使用 x64？除了每次 64 位设备上的人获得最新版本时手动更新引用之外，还有其他解决方案吗？
【问题讨论】：
标签： .net visual-studio x86 64-bit
【发布时间】：2010-10-11 15:40:18
【问题描述】：
您想将此作为构建的一部分，对吗？
编写一个预构建步骤，将引用的 DLL 从源代码树中的永久位置复制到本地项目。使用 $(ConfigurationName) 或 $(PlatformName) 宏来选择实际复制的非托管 DLL 的版本。您只需将 DLL 保存在名称与配置名称或平台名称匹配的单独文件夹中。
【讨论】：
-
其实这是在设计时。我们已经为构建过程提供了解决方案，但是一些开发人员实际上在 Debug | 中进行了编译。 x64。
使用 x64 机器的开发人员愿意运行 64 位版本是相当奇怪的。 Visual Studio 不支持 x64 模式下的 Edit+Continue，那是相当损失的。解决方法很简单，将 Platform Target 设置为 x86。还自动解决您的非托管 DLL 问题。
【讨论】：
-
很奇怪，我会和三只害群之马讨论，但如果有解决方案就更好了。我想这是一个非常边缘的案例，但我会继续寻找。
还有另一种解决方案，涉及稍微编辑您的代码。从Milan Gardian 到this question 的答案中对此进行了描述。
基本上，它涉及编写您自己的程序集引用处理程序以确定在运行时加载哪个程序集，前提是您可以访问程序集的两个（32 位和 64 位）版本。我刚刚自己实现了这个解决方案，它就像一个魅力。
我的情况是这样的：
我正在开发一个针对 Windows 7 64 位上的“任何 CPU”的 .NET 程序。我添加了 32 位程序集引用，并将 Copy Local 设置为 false。我使用构建后事件将 32 位和 64 位程序集复制到输出文件夹，并确保为 32 位程序集指定与参考文件中不同的名称。这是因为我想强制我的自定义程序集解析器启动并执行其操作，因为 .NET 的默认程序集解析器无法解析引用。在运行时加载了正确的程序集，并且在编译时我没有收到任何错误。应该注意的是，我还没有时间真正确认它现在可以在 32 位操作系统上运行，但我看不出它不应该运行的任何原因。
【讨论】：