VS 2010项目始终以x86 / 32位为目标

Question

I have a project that seems to always be targeting x86/32 bit and I can't find out why. I have gone through all the projects in solution and made sure the PlatformTarget is AnyCPU.

Using dumpbin to examine all the binaries I get '14C machine (x86)'.

The build machine is x64 although previously was x86.

What else could be causing this and what should I check?

Answer 1

You must be talking about the output you see from Dumpbin.exe with the /headers option. Which looks like this when run on a .NET assembly that's compiled with the platform target set to AnyCPU:

Dump of file ConsoleApplication1.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               3 number of sections
        4E3E987F time date stamp Sun Aug 07 08:51:59 2011
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             102 characteristics
                   Executable
                   32 bit word machine
etc..

Yes, the IMAGE_FILE_HEADER.Machine value is set to 0x14c, the value of IMAGE_FILE_MACHINE_I386 (aka x86). This is of no consequence, perhaps the strongest hint that it is not relevant is the target name: AnyCPU. It runs as well on an x86 as on an x64 operating system.

What you really want to use is corflags.exe, it shows you the COR header in the file:

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 1
ILONLY    : 1
32BIT     : 0
Signed    : 0

The 32BIT flag is the important one, 0 indicates that AnyCPU was used. ILONLY = 1 indicates that the assembly contains IL only, no machine code. It will be 0 when you create assemblies with the C++/CLI language.

You can create an image file with the machine set to x64. I think that was introduced in .NET 3.0 (aka .NET 2.0 SP1). If you set the platform target to x64 then the machine type field will be set to IMAGE_FILE_MACHINE_AMD64 (aka x64). That doesn't make much difference, other than that the program will never run on a 32-bit operating system and that the main thread will get started with a 4 megabyte stack instead of a 1 MB stack.

The magic that turns a 32-bit executable image into a 64-bit process is described in this answer .