为什么.NET开发人员提供32位/ 64位版本的.NET程序集?

时间:2009-01-17 23:37:00

标签: .net 64-bit jit

Evey现在我看到了.NET程序集的x86和x64版本。请考虑以下web part for SharePoint。为什么开发人员不会只提供单个版本并让JIT编译器对其余版本进行排序?当我看到这些类型的产品时,开发人员决定使用像ngen这样的工具来创建原生图像以避免JIT?

有人请帮助我,我觉得我错过了一些注意事项。

更新

根据我的内容,提供x86和x64版本是因为以下一个或多个原因:

  1. 开发人员希望避免JITing并创建他的代码的原生图像,使用像ngen.exe这样的工具瞄准给定的体系结构。

  2. 程序集包含特定于平台的COM调用,因此无需将其构建为AnyCPU。在这些情况下,针对不同平台的构建可能包含不同的代码。

  3. 程序集可能包含使用pinvoke的Win32调用,它不会被JIT重新映射,因此构建应该以它所绑定的平台为目标。

3 个答案:

答案 0 :(得分:6)

如果他们使用特定的非.Net API,那么可能有两个代码库,一个完美的例子是COM控件。

正如你所提到的,ngen也是另一个很好的理由。

答案 1 :(得分:6)

编译.net应用程序时,必须在Build Settings中选择一个Platform Target。选择是AnyCPU,x86和x64。

常见的错误是在项目中指定AnyCPU,其中包括为x86编译的本机DLL。这将导致在64位计算机上运行时出错,这是在64位计算机上进行测试的一个很好的理由。

因此,为了支持被其他依赖项强迫的人直接为x86或x64构建,程序集会同时提供这两者。

答案 2 :(得分:0)

COM处理跨32/64位边界的编组和解组。但是,它没有提供任何支持将替代类型的二进制文件加载到公寓的错误指针宽度。

许多程序集依赖于本机代码(例如,大多数SQL驱动程序都是用C或C ++编写的)。对于使用p / invoke的任何东西,这都是非常明显的;因此,编译和分发不同的指针宽度意味着64位版本的软件包很可能包含64位本机DLL,而32位版本可能包含32位本机DLL。即使32位和64位版本的程序集是使用相同的代码编译的,也是如此。

如果您要求,csc将生成本机(预先JIT)图像。