为什么.net程序集对于不同的体系结构有所不同?

按照我的理解,这个设置是一个标志,上面写着“程序集应该在这种类型的体系结构中运行”。这是针对x86和x64设置的。MSIL/.NET设置只是说“我不在乎,我可以在其中任何一个上运行,所以选择一个最佳的或可用的。”

例如,您可能通过P/Invoke调用Win32 API函数,在这种情况下,程序集将无法在x64上工作,您应该将其标记为x86。

Setting        x86      x64  <-- Platform (CPU/OS)
MSIL/.NET     32-bit   64-bit
x86           32-bit   32-bit
x64           N/A (*)  64-bit

x86上x64程序集的N/A意味着该程序集将不会加载,如果您尝试加载,将出现异常。

明显地 通常,如果您没有调用标记为特定内容的程序集,并且只要您没有执行不能跨32位和64位移植的P/Invoke(我不知道这是否有效,P/Invoke to win api函数是否会映射到正确的位大小的dll),就需要使用MSIL设置

由于引用是指针,指针作为本地x位地址存储在两个平台上,这取决于引用的数量,因此 可以

该标志对于EXE文件很重要。它决定您是在32位还是64位进程中运行。如果从.NET代码中使用“本机”DLL,则需要遵循这些DLL的体系结构。

EXE文件上的“任意CPU”将选择x64(如果可用)。

首先,在64位版本的Windows上调试项目时,在.exe项目中将平台目标设置为x86非常有用。VS2005/8调试器不支持64位代码上的“编辑+继续”。

如果您的程序依赖于只在32位代码中工作的组件,那么在发布版本中选择x86是您应该做的事情。这并不少见,有很多COM组件从来没有也永远不会被移植到64位非托管代码中。一个典型的例子是Microsoft Jet数据库引擎。

选择x64是非常不寻常的,没有多少非托管代码仅在64位版本中可用。值得注意的是,当您构建程序集时会收到警告,有几个.NET framework程序集包含非托管代码;在c:\windows\microsoft.net中只有32位版本可用。您可以安全地忽略这些警告,64位版本实际上安装在GAC中。

选择x64时的一个问题是,C#3.0编译器将发出一个二进制文件,要求Windows创建堆栈大小为4 MB的启动线程,而不是默认的1 MB。这有点道理,64位代码确实需要更多的堆栈来存储指针和返回地址。

最后,Windows SDK具有Corflags.exe工具,可用于在生成程序集后切换程序集的位。/32BIT+选项相当于将平台目标设置为x86。使用/32位-确保程序集在64位操作系统上以64位模式运行。可以使用Editbin.exe工具更改默认堆栈大小。

我认为存在不同目标的原因在于标量类型的大小。我认为这也会影响COM对象的处理方式。