There's a nice little (and dangerous) tool present in every .NET Framework SDK.
It's called corflags.exe. If you run it, you might get something like this:
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v2.0.50727
CLR Header: 2.5
PE : PE32
CorFlags : 1
ILONLY : 1
32BIT : 0
Signed : 0
What this tells you (via the CLR Header) is that testme.exe assembly hides a .NET Framework 2.0 compiled code. All 2.0 framework code will have 2.5 header version, while all 1.0/1.1 compiled code will have 2.0 header version. It's a bit of a mess, but noone can change history.
Next important value is PE. It tells you whether this assembly is a 32-bit or 'any cpu' compiled assembly. If PE value should be 'PE32+' than you could conclude that this is a 64-bit capable assembly.
The 32BIT property, contrary to its name, does not represent bitness of the assembly. In this case, 32BIT property holds a value of 0, which would mean that this is a 64-bit assembly. Actually this assembly can be run anywhere, since it was compiled with agnostic setting of 'any cpu'. If I wanted to, I could turn this knob using the following:
corflags.exe /32BIT+ testme.exe
Now, this assembly would always execute under WoW64 (emulated 32-bit environment on a 64-bit box). In a case where this execution would not be possible - ie. run against an ia64 box - one would get a BadImageFormatException exception.
There is no way (for now) to demand execution in a 64-bit process because this thing is not controled by a metadata flag. Rather it's controled at compile time and compiler has to emit PE32+ compatible code.
Recap: CLR Header property denotes compiler version which was used to produce the assembly. PE property tells you whether this assembly is either 32-bit (PE32), 'any cpu' (PE32) or 64-bit (PE32+). If the 32BIT property is set it mandates execution in a 32-bit process, if the platform allows it.