At work, I was faced with a problem of a .NET program looking at the wrong registry values, and picking up the wrong machine.config. You see, a 32-bit application running on 64-bit Windows is supposed to be presented with its own 32-bit view of the machine, from registry entries to system DLLs. This is all pretty spectacular, which is why they call it WOW. For more information on WOW64, Wikipedia is your friend.
.NET is a bit tricky, though. By default, .NET applications are compiled with the /platform:anyCPU [MSDN /platform documentation]. This means they will run as 32-bit applications on 32-bit systems, and as 64-bit applications on 64-bit systems. When a .NET application is part of a larger system of applications, this can cause incompatibilities. All the regular C-compiled executables will run in 32-bit, but your .NET app will be interacting with the 64-bit environment and be out of sync.
To solve this, you can simply specify /platform:x86 when part of a 32-bit package, and /platform:x64 when part of a 64-bit package.
The next question is: How do I know if a .NET program was compiled with the /platform option specified as x86, x64, or anyCPU?
For regular applications, a Google search yielded the following blog post on using dumpbin to determine if it is a 32-bit or 64-bit application. For .NET applications, using dumpbin /HEADERS isn't quite enough. Programs compiled with the anyCPU option will still show up as:
14C machine (x86)
32 bit word machine
Dumpbin has other options, though, and /CLRHEADER comes to the rescue. For anyCPU applications, the relevant portion is:
1 flags
IL Only
x86 applications get:
B flags
IL Only
32-Bit Required
Dumpbin is a highly useful diagnostic tool, as I find out often.
Update: I just tried dumpbin on an /platform:x86 application running on 32-bit Windows, and the "flags" attribute had no lines beneath it, but it looks like the "1" vs "B" is still accurate. Perhaps this expansion is new in Visual Studio 2008's dumpbin.
No comments:
Post a Comment