Geek Answers Handbook

Why do .NET developers offer 32-bit / 64-bit versions of .NET collections?

Evey from time to time I see both versions of x86 and x64 of the .NET assembly. Consider the following web part for SharePoint . Why would the developer not offer a single version and prevent the JIT compiler from parsing the rest? When I see this suggestion, is it just that the developer decided to create his own image using a tool like ngen to avoid JIT?

Someone, please help me here, I feel that I am missing something remarkable.

Update

From what I got below, both x86 and x64 builds are offered due to one or more of the following reasons:

  • The developer wanted to avoid JITing and create his own image of his code focused on this architecture using a tool such as ngen.exe.

  • The assembly contains platform-specific COM calls and therefore it makes no sense to build it like AnyCPU. In these cases, assemblies that are targeted by different platforms may contain different codes.

  • The assembly may contain Win32 calls using pinvoke, which will not be reassigned to JIT, so the assembly must be oriented to the platform to which it is attached.

+6
64bit jit
source share
3 answers

If they use a specific non-NO API, then there can be two code bases for this, an ideal example of which is COM control.

ngen is also another very good reason for this, as you mentioned.

+6
source share

When compiling a .net application, you must select the Target Platform in the build settings. Options are AnyCPU, x86 and x64.

A common mistake is to specify AnyCPU in the project, which includes its own DLL files compiled for x86. This will lead to errors when working on 64-bit machines, which is a good reason for testing on a 64-bit machine.

Therefore, in order to support people who are forced to run other build dependencies for x86 or x64 directly, the assembly offers both.

+6
source share

COM handles marshaling and unwinding across 32/64 bit boundaries. However, it does not provide support for loading an alternate type of binary into the wrong line width.

Many assemblies rely on native code (most SQL drivers are written, for example, in C or C ++). This is incredibly obvious for anything using p / invoke; thus, compiled and distributed different pointer parameters means that the package for the 64-bit version most likely contains 64-bit native DLLs, and the 32-bit version probably contains 32-bit native DLL files. This is the case even if the 32 and 64-bit versions of the assembly are compiled from the same code.

csc will produce its own (pre-JITted) images if you ask for it.

0
source share

More articles:


All Articles