.NET编译的目标平台(AnyCPU,x86,x64)

转载:http://blog.sina.com.cn/s/blog_78b94aa301014i8r.html

今天有项目的代码收到客户的反馈,要求所有的EXE工程的目标平台全部指定成x86,而所有DLL工程的目标平台全部指定成AnyCPU 。

下面我们一起看看这个目标平台有什么作用,各选项有什么差别吧。

在VisualStudio中,在编译设置中有如下选项:

x86: 将程序集编译为由兼容 x86 的 32 位公共语言运行库运行。

x64: 将程序集编译为由支持 AMD64 或 EM64T 指令集的计算机上的 64 位公共语言运行库运行。

anycpu:(默认值)将程序集编译为在任意平台上运行。

Itanium: 将程序集编译为由采用 Itanium 处理器的计算机上的 64 位公共语言运行库运行。

具体行为如下:

在 64 位 Windows 操作系统上:

用 x86 编译的程序集将在 WOW64 下运行的 32 位 CLR 上执行。

用 x64 编译的程序集将在 64 位 CLR 上执行。

用 anycpu 编译的可执行文件将在 64 位 CLR 上执行。

用 anycpu 编译的 DLL 将在与加载它的进程相同的 CLR 上执行。

在 32 位 Windows 操作系统上:

用 x86或anycpu 编译的程序集将在 32 位 CLR 上执行。

用 x64 编译的程序集无法运行。

搞清楚这些差异以后,回过头来看看客户要求的东西,有没有道理吧。

首先有一点是知道的,客户希望程序能够在WINXP以上的各系统中运行(不管是32位还是64位)。

因此,不可能选x64,Itanium这种针对特殊处理器的也不会去选。

那都选择Any CPU这种默认方式有没有问题呢?

首先看看Any CPU和x86的可执行文件(EXE)在32位和64位下有什么区别吧,

Any CPU在32位下,EXE将以32位执行,而在64位下,EXE将以64位执行。而x86的话,始终以32位执行。

客户希望使用的x86,也就是不希望64位下用64位方式执行EXE程序。我分析的原因是由于系统中可能存在第三方的32位DLL,一旦使用64位执行的EXE,在调用到32位的DLL时,将无法调用。

而DLL,客户则希望采用Any CPU,我分析的原因是DLL的实际运行方式是受调用它的EXE所影响的,因此设为Any CPU就可以了。而如果设定为x86,虽然看似没什么问题,但其无法在64位CLR中运行了,不是太好。

参考资料:

http://msdn.microsoft.com/zh-cn/library/zekwfyz4(VS.80).aspx

------------------------------

补充一下,可以使用.NET SDK中提供的CorFlags命令查看程序集的目标平台,也可以修改它,这样就可以不用重新编译了。不过,为啥64位下的EXE无法调用32位的DLL呢?

时间: 2024-09-28 19:38:40

.NET编译的目标平台(AnyCPU,x86,x64)的相关文章

关于.NET编译的目标平台(AnyCPU,x86,x64)

今天有项目的代码收到客户的反馈,要求所有的EXE工程的目标平台全部指定成x86,而所有DLL工程的目标平台全部指定成AnyCPU . 下面我们一起看看这个目标平台有什么作用,各选项有什么差别吧. 在VisualStudio中,在编译设置中有如下选项: x86: 将程序集编译为由兼容 x86 的 32 位公共语言运行库运行. x64: 将程序集编译为由支持 AMD64 或 EM64T 指令集的计算机上的 64 位公共语言运行库运行. anycpu:(默认值)将程序集编译为在任意平台上运行. Ita

关于.NET编译的目标平台(AnyCPU,x86,x64)(转)

今天有项目的代码收到客户的反馈,要求所有的EXE工程的目标平台全部指定成x86,而所有DLL工程的目标平台全部指定成AnyCPU . 下面我们一起看看这个目标平台有什么作用,各选项有什么差别吧. 在VisualStudio中,在编译设置中有如下选项: x86: 将程序集编译为由兼容 x86 的 32 位公共语言运行库运行. x64: 将程序集编译为由支持 AMD64 或 EM64T 指令集的计算机上的 64 位公共语言运行库运行. anycpu:(默认值)将程序集编译为在任意平台上运行. Ita

关于VS项目平台的x86,x64,Any CPU以及Debug和Release的区别

相信对于很多刚接触打包程序的同志来说,关于x86,x64,Any CPU这三个项目平台,以及解决方案配置Debug和Release有什么区别?这个问题一定有许多的困惑,甚至不乏一些已经工作了很久的老程序猿来说都是一个模棱两可的问题.当然,我也是捣腾了好久,才渐渐搞明白它们的区别,以此作个总结: 一 .x86.x64.Any CPU的区别 1.简单的说,它们之间最直接的区别就是:x86平台编译出来的exe(可执行文件)或dll(动态链接库)都是32位的.以此类推,x64对应的则是64位的.而Any

QT5.7.0在win10下使用visual studio 2015编译(目标平台 xp)

环境:win10+vs2015+QT5.7.0 目标:编译出能在windows xp上运行的QT 通过baidu和bing找不出来的结果没有一个能成功运行,大部分都能编译成功,并完美解决“exe不是有效的win32程序”,但是程序依旧没法正常显示窗口. 此时会有一个crash,具体位置是qwindows.dll,但是使用depends查看也没看出来qwindows.dll有问题,有些人会遇到qwindows.dll依赖的 kernel32.dll在xp下没有对应接口,具体接口不记得了,最后看到是

目标平台选项对生成的模块及运行时的影响

.NET程序在编译之前,修改目标平台唯一会影响到的就是编译之后的程序集.而对程序集的影响具体体现在哪里呢,下面就来说一说. 在生成的程序集中存在几部分,他们是程序集的组成部分,当然归根到底还是磁盘上的一部分空间而已.这里边有MS-DOS占位程序.COFF头.PE头等等(当然还包含很多,具体可以查相关资料).PE头的第一个字段标识的是Magic字段.也就是说,在编译之前修改的目标平台属性会导致生成的程序集的相应字段改变.这种改变体现在运行时的不同. 运行一个可执行文件,Windows会检查这个可执

关于wcf服务编译平台是x86, 运行平台是x64时,如何调试

关于调试CTDC项目中的的 wcf服务时注意事项: 因为wcf项目引用的的 x86的程序集,所以wcf生成的目标平台为x86.故在64系统上调试需要执行下面的脚本 具体操作步骤: 1. 进入目录:C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE 2. 执行下面指令:corflags /32BIT+ /Force WcfSvcHost.exe 3. 取消模式:corflags /32BIT- /Force WcfSvcH

『开源重编译』System.Data.SQLite.dll 自适应 x86 x64 AnyCPU 重编译

背景: > System.Data.SQLite.dll 程序集 不能良好的支持 AngCPU 格式 System.Data.SQLite.dll 在 适应 x86 和 x64 有三个方案: > 分别使用 32 或 64 的 混合编译程序集(程序如果以64位 运行,但引用32位的 程序集 就会报错,反之) —— 所以这种方案 很惹人嫌. > 使用 AnyCPU 的程序集 —— 但是 你得间接引用 C++ 核心程序集:SQLite.Interop.dll —— 即:你得 同时引用 两个程序

检查.net dll构建的目标平台是any cpu、x86、x64

有时候,需要检查构建的dll是否针对正确的平台 可以使用CorFlags.exe(它是.NET Framework SDK的一部分)从dll中查找此信息.运行CorFlags.exe将产生以下输出: >> CorFlags "C:\example.dll" Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.6.1590.0 Copyright (c) Microsoft Corporation.

64位系统上设置编译平台为x86的项目编译在特定的情况下比如当一个窗体上放有包含了图像的ImageList之后,ResGen就会产生这种问题

随笔 - 1  文章 - 0  评论 - 3 未能加载文件或程序集“****”或它的某一个依赖项.试图加载格式不正确的程序.解决方案总结 当这个ImageList中没有图像时编译也是正常的,但是一旦编译就会引发这样的异常. 这个错误产生的原因在于,VS2010内部使用的编译器中,无论是32位还是64位的编译组件,都是纯IL的,也就是在64位系统中是以64位模式运行,这与当前项目使用的平台设置无关.当编译的组件引用了一个标记为x86的库(仅32位模式)时,编译组件便会发生错误,无法加载,从而导致编