这个问题与之前关于SO的问题有关
我有一个应用程序,最初是使用Visual Studio 2005在Win XP上构建的(不要笑!).这个应用程序调用我们的win32 C++ DLL.调用C++ dll的C#组件是使用"Any CPU"配置构建的,并且很乐意在Win XP上运行,没有任何问题.
我们现在转向Win 7,我们的应用程序的发布版本(使用VC 2005构建在Win XP上)运行良好.然而,随着win 7向我们的用户推出,我们现在已经采取了机会转移到VS 2010并且我已经使用VC 2010在win 7上构建了C#组件,但是现在运行这个版本时我得到很多"无法加载abc. dll"其中abc.dll是我们的win32 c ++组件.
我知道用x86配置重新编译C#程序集将解决问题,但我不明白的是,使用Win-XP/Visual studio 2005(任何CPU配置)构建的发行版c#程序集如何能够在Win 7上运行任何问题?当然,这些使用"任何CPU"构建的C#程序集在Win 7中加载时应该JIT到64位代码并导致BadImageFormatException或其他错误,因为它们调用Win32 C++ dll.
更新:我在下面的评论中提供了更多信息.
在我的Windows 7机器上,我右键单击我的计算机并查看属性.系统信息显示"系统类型:64位操作系统",确认这是一个Win64操作系统.
在Windows XP上打开VC2005中的解决方案在查看解决方案的配置管理器时,我可以确认所有 C#项目都是平台类型"任何CPU".
在64位Win 7机器上运行发布版本(在VC2005/win xp上完成)时,我的任务管理器将图像名称显示为"Test.exe*32",这确认它是jit'd并加载到32位进程中.
Win7下,进程是64位的。64 位进程中不能包含 32 位 DLL,这是 Windows 的一个非常基本的设计限制。
事实上,这个托管代码 EXE 调用 32 位 DLL 从一开始并不明显 - P/Invoke 以及 COM 互操作都是通过后期绑定工作的。因此,加载 EXE 时,加载程序不会检查依赖关系 - 一方面,依赖关系可能是有条件的 - 然后 DLL 加载时间到来,古怪的事情随之而来。
所以,是的,如果您有具有已知 32 位依赖项的托管代码,您最好在编译时指定 32 位 CPU。或者将 C++ 部分重新编译为 64 位,这也是一种选择。
| 归档时间: |
|
| 查看次数: |
3420 次 |
| 最近记录: |