3

What do we do if we have some devs working on 64 bit machines and some on 32 bit machines, but we need to reference unmanaged assemblies that need to be in x86 for half the team and x64 for the other half? Is there a solution besides manually updating the references every time someone on a 64 bit rig gets latest?

4

3 回答 3

1

您想将此作为构建的一部分,对吗?

编写一个预构建步骤,将引用的 DLL 从源代码树中的永久位置复制到本地项目。使用 $(ConfigurationName) 或 $(PlatformName) 宏来选择实际复制的非托管 DLL 的版本。您只需将 DLL 保存在名称与配置名称或平台名称匹配的单独文件夹中。

于 2009-03-06T01:53:12.103 回答
1

使用 x64 机器的开发人员愿意运行 64 位版本是相当奇怪的。Visual Studio 不支持 x64 模式下的 Edit+Continue,那是相当损失的。解决方法很简单,将 Platform Target 设置为 x86。自动也解决您的非托管 DLL 问题。

于 2009-03-06T13:37:10.070 回答
0

还有另一种解决方案涉及稍微编辑您的代码。Milan Gardian对此问题的回答中对此进行了描述。

基本上,它涉及编写您自己的程序集引用处理程序以确定在运行时加载哪个程序集,前提是您可以访问程序集的两个(32 位和 64 位)版本。我刚刚自己实施了这个解决方案,它就像一个魅力。

我的情况是这样的:
我正在开发一个针对 Windows 7 64 位上的“任何 CPU”的 .NET 程序。我添加了 32 位程序集引用,并将 Copy Local 设置为 false。我使用构建后事件将 32 位和 64 位程序集复制到输出文件夹,并确保为 32 位程序集提供与参考文件中不同的名称。这是因为我想强制我的自定义程序集解析器启动并执行它的操作,因为 .NET 的默认程序集解析器无法解析引用。在运行时加载了正确的程序集,并且在编译时我没有收到任何错误。应该注意的是,我还没有时间真正确认它现在可以在 32 位操作系统上运行,但我看不出它不应该运行的任何原因。

于 2009-09-18T20:31:32.287 回答