How to determine an assembly's target platform?

[Object01]

We're working with some benchmarks designed to test x86 vs. x64
performance (both on a x64 system). To ensure that our assemblies are
loaded as x86 or x64, we specifically target our builds to the
appropriate platform, avoiding using the "Any CPU" setting. (It's my
understanding that on an x64 system, the runtime will JIT an "Any CPU"
assembly as x64 if it's able.)

All this raised an interesting question: given an arbitrary .NET
assembly, how can I tell how it was compiled? ILDASM shows me the PE
header, and I've found sections labeled "PE Optional Header (64 bit)"
in assemblies specifically targeted to x64. But assemblies targeted
to "Any CPU" -and- assemblies targeted to x86 seem to have "PE
Optional Header (32 bit)", leaving some ambiguity. Is there a sure-
fire way to tell? A flag among all that hex, perhaps?

 

[Barry Kelly]

We're working with some benchmarks designed to test x86 vs. x64
performance (both on a x64 system). To ensure that our assemblies are
loaded as x86 or x64, we specifically target our builds to the
appropriate platform, avoiding using the "Any CPU" setting. (It's my
understanding that on an x64 system, the runtime will JIT an "Any CPU"
assembly as x64 if it's able.)

All this raised an interesting question: given an arbitrary .NET
assembly, how can I tell how it was compiled? ILDASM shows me the PE
header, and I've found sections labeled "PE Optional Header (64 bit)"
in assemblies specifically targeted to x64. But assemblies targeted
to "Any CPU" -and- assemblies targeted to x86 seem to have "PE
Optional Header (32 bit)", leaving some ambiguity. Is there a sure-
fire way to tell? A flag among all that hex, perhaps?

If you done the ildasm, you can see that .corflags is the relevant
field:

..corflags 0x00000001 // ILONLY

versus:

..corflags 0x00000003 // ILONLY 32BITREQUIRED

It's part of the CLI header, 'Flags' field. The CLI header is pointed to
by the an entry in the PE header directories, that follow PE optional
header. It's the 15th (RVA,Size) pair (aka directory entry) in that
list. The relevant details are in the ECMA 335 specification.

-- Barry

 

[Object01]

We're working with some benchmarks designed to test x86 vs. x64
performance (both on a x64 system). To ensure that our assemblies are
loaded as x86 or x64, we specifically target our builds to the
appropriate platform, avoiding using the "Any CPU" setting. (It's my
understanding that on an x64 system, the runtime will JIT an "Any CPU"
assembly as x64 if it's able.)

All this raised an interesting question: given an arbitrary .NET
assembly, how can I tell how it was compiled? ILDASM shows me the PE
header, and I've found sections labeled "PE Optional Header (64 bit)"
in assemblies specifically targeted to x64. But assemblies targeted
to "Any CPU" -and- assemblies targeted to x86 seem to have "PE
Optional Header (32 bit)", leaving some ambiguity. Is there a sure-
fire way to tell? A flag among all that hex, perhaps?

I think I found a solution at http://blogs.msdn.com/gauravseth/archive/2006/03/07/545104.aspx.
The PETYPE and 32BIT flags can be used to determine the targeted
platform.

 

[Object01]

If you done the ildasm, you can see that .corflagsis the relevant
field:

.corflags0x00000001 // ILONLY

versus:

.corflags0x00000003 // ILONLY 32BITREQUIRED

It's part of the CLI header, 'Flags' field. The CLI header is pointed to
by the an entry in the PE header directories, that follow PE optional
header. It's the 15th (RVA,Size) pair (aka directory entry) in that
list. The relevant details are in the ECMA 335 specification.

-- Barry

--http://barrkel.blogspot.com/

Am I interpreting ECMA 335 correctly when it says ($24.1) that ILONLY
should be ignored when read? By this reading, why would ILONLY ever
be 0, as it is in so many of the assemblies I've examined?

 

[Barry Kelly]

Am I interpreting ECMA 335 correctly when it says ($24.1) that ILONLY
should be ignored when read? By this reading, why would ILONLY ever
be 0, as it is in so many of the assemblies I've examined?

AFAIK, in e.g. C++/CLI assembly with mixed native code (/clr), it won't
necessarily be present.

-- Barry