What AnyCPU Really Means As Of .NET 4.5 and Visual Studio 11
The 32-bit and 64-bit development story on Windows seemingly never stops causing problems for developers. It’s been a decade since 64-bit processors have started popping up in the Windows consumer environment, but we just can’t get it right. If you forget some of the gory details, here are a couple of reminders:
- On a 64-bit Windows system, both the 32-bit and 64-bit versions of system DLLs are stored. The 64-bit DLLs are in C:\Windows\System32, and the 32-bit DLLs are in C:\Windows\SysWOW64.
- When a 32-bit process opens a file in C:\Program Files, it actually reads/writes to C:\Program Files (x86).
- There are separate views of (most of) the registry for 32-bit and 64-bit applications. You can change the 64-bit registry location and it wouldn’t be visible to 32-bit applications.
These differences are hardly elegant as they are, but they allow 32-bit applications to run successfully on a 64-bit Windows system. While unmanaged applications always had to choose the native target—x86, x64, or ia64 in the Visual Studio case—managed code has the additional choice of AnyCPU. （也就是说只有托管代码有AnyCPU选项，普通的C++代码编译时候只能选X86、X64、ia64）
What AnyCPU used to mean up to .NET 4.0 (and Visual Studio 2010) is the following:
- If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
- If the process runs on a 64-bit Windows system, it runs as a 64-bit process. IL is compiled to x64 machine code.
- If the process runs on an Itanium Windows system (has anyone got one? ;-)), it runs as a 64-bit process. IL is compiled to Itanium machine code.
Prior to Visual Studio 2010, AnyCPU was the default for most .NET projects, which was confusing to some developers: when they ran the application on a 64-bit Windows system, the process was a 64-bit process, which may cause unexpected results. For example, if the application relies on an unmanaged DLL of which only a 32-bit version is available, its 64-bit version won’t be able to load that component.
In Visual Studio 2010, x86 (and not AnyCPU) became the default for most .NET projects—but otherwise the semantics haven’t changed.
In .NET 4.5 and Visual Studio 11 the cheese has been moved. The default for most .NET projects is again AnyCPU, but there is more than one meaning to AnyCPU now. There is an additional sub-type of AnyCPU, “Any CPU 32-bit preferred”, which is the new default (overall, there are now five options for the /platform C# compiler switch: x86, Itanium, x64, anycpu, and anycpu32bitpreferred). When using that flavor of AnyCPU, the semantics are the following:
- If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
- If the process runs on a 64-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
- If the process runs on an ARM Windows system, it runs as a 32-bit process. IL is compiled to ARM machine code.
The difference, then, between “Any CPU 32-bit preferred” and “x86” is only this: a .NET application compiled to x86 will fail to run on an ARM Windows system, but an “Any CPU 32-bit preferred” application will run successfully.
To inspect these changes, I created a new C# console application in Visual Studio 11 that prints the values of Environment.Is64BitOperatingSystem and Environment.Is64BitProcess. When I ran it on my 64-bit Windows system, the result was as follows:
Is64BitOperatingSystem = True
Is64BitProcess = False
Inspecting the project’s properties shows the following (in the current Visual Studio UI “Prefer 32-bit” is grayed out and unchecked, where in actuality it is enabled…):
Inspecting the executable with CorFlags.exe shows the following:
Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 131075
ILONLY : 1
32BITREQ : 0
32BITPREF : 1
Signed : 0
After changing the 32BITPREF setting with CorFlags.exe (using the /32bitpref- option), the output was as follows:
Is64BitOperatingSystem = True
Is64BitProcess = True
在X86操作系统上：
| 目标平台 | 程序类型 | 运行结果 |
| X86 | 应用程序exe | 在32位CLR上运行 |
| X86 | 类库dll | 在32位CLR上运行 |
| X64 | 应用程序exe | 无法运行 |
| X64 | 类库dll | 无法运行 |
| AnyCPU | 应用程序exe | 在32位CLR上运行 |
| AnyCPU | 类库dll | 在32位CLR上运行 |
在X64操作系统上：
| 目标平台 | 程序类型 | 运行结果 |
| X86 | 应用程序exe | 在WOW下的32位CLR上运行 |
| X86 | 类库dll | 在WOW下的32位CLR上运行 |
| X64 | 应用程序exe | 在64位CLR上运行 |
| X64 | 类库dll | 在64位CLR上运行 |
| AnyCPU | 应用程序exe | 在64为CLR上运行 |
| AnyCPU | 类库dll | 在与加载它的主程序相同的CLR上运行 |
举几个例子：
| 主程序 | Dll | X86操作系统 | X64操作系统 |
| 目标平台X86 | 目标平台X86 | 在32位CLR上运行 | 在WOW下的32位CLR上运行 |
| 目标平台X86 | 目标平台X64 | X | X |
| 目标平台X86 | 目标平台AnyCPU | 在32位CLR上运行 | 在WOW下的32位CLR上运行 |
| 目标平台X64 | 目标平台X64 | X | 在64位CLR上运行 |
| 目标平台X64 | 目标平台X86 | X | X |
| 目标平台X64 | 目标平台AnyCPU | X | 在64位CLR上运行 |
| 目标平台AnyCPU | 目标平台X64 | X | 在64为CLR上运行 |
| 目标平台AnyCPU | 目标平台X86 | 在32位CLR上运行 | X |
| 目标平台AnyCPU | 目标平台AnyCPU | 在32位CLR上运行 | 在64位CLR上运行 |
一般来讲，我们可以把主程序的目标平台根据实际需求设置为跟部署的操作系统一致，类库最好是AnyCPU。当然特殊的部署环境还要特殊考虑。
对于托管DLL或EXE，我们可以使用CorFlags.exe工具来查看它的目标平台，
找到corflags.exe + dll位置 "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\CorFlags.exe" dll_name
· anycpu: PE = PE32 and 32BIT = 0
· x86: PE = PE32 and 32BIT = 1
· 64-bit: PE = PE32+ and 32BIT = 0
例如：
若使用CorFlags.exe查看非托管DLL或EXE，则会报错，如下：
使用dumpbin.exe也可以查DLL或者EXE是32位或者64位的，这个对托管和非托管都管用。
"D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\dumpbin.exe" /headers dll_name，例如：
使用dumpbin还可以查看dll暴露出的接口：
"D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\dumpbin.exe" /exports dll_name
例如：
