Visual Studio Hacks

Visual Studio .NET Platform Target Explained

by dstokes on August 6, 2008

The Platform Target is an often overlooked option in the build configuration for Visual Studio 2005 and 2008 projects.  For C# projects, you will find this option on the Project Properties dialog under the build tab.  For projects, the setting is found on the Advanced Compiler Settings dialog which is made available via the Advanced Compile Options button on the Compile tab of the Project Properties.  The list of available options are:

  1. Any CPU
  2. x86
  3. x64
  4. Itanium

The meaning of these options is often misunderstood.  Based on their names, one might think that the compiler will generate code differently based upon the setting.  However, the C# and compilers only generate IL code that is taken to native code by the CLR at runtime using the just-in-time compiler (unless ngen is used but that is another discussion).  The fact is that this setting actually does not affect the build of the assembly in any way except to set the platform status information on the assembly’s CLR header.  In other words, the Platform Target setting is meant to communicate the platform that the developer intends to be compatible with.

The default setting, Any CPU, means that the assembly will run natively on the CPU is it currently running on.  Meaning, it will run as 64-bit on a 64-bit machine and 32-bit on a 32-bit machine.  If the assembly is called from a 64-bit application, it will perform as a 64-bit assembly and so on.

If the project is set to x86, this means the project is intended to run only as a 32-bit process.  A 64-bit process will be unable to call into an assembly set as X86.  Reasons to set your project as x86 include dependencies upon native DLLs that are only available in 32-bit or making native calls assuming 32-bit .  Applications and assemblies marked for x86 can still run on 64-bit Windows.  However they run under WOW64.  Visual Studio itself runs under this emulation mode since it is a 32-bit application.

Setting the project to x64 will specify that the assembly must run under 64-bit Windows.  Attempting to run the assembly on 32-bit Windows or call the assembly from a 32-bit process will result in a runtime error.

The final, and likely least common, setting is Itanium.  This setting specifies that the assembly will only run on an Itanium processor.  The only reason to set your project for Itanium is if it has dependencies on native DLLs compiled specifically for the Itanium processor.

Developers should be aware that simply marking Platform Target of an assembly as Any CPU does not guarantee that it will run on both 32-bit and 64-bit Windows.  In fact, since Any CPU is the default setting, there are likely many applications that actually depend upon 32-bit processing but are not marked as such.  These assemblies will fail under 64-bit Windows when run from a 64-bit process so it is important to perform testing for your applications before users are migrated to 64-bit.  The somewhat increasing popularity of Vista x64 will soon elevate the importance of this type of testing.

Another point to be aware of when attempting to migrate to 64-bit processing for .Net applications is the dependency upon assemblies originally built using Visual Studio 2002 and 2003.  All assemblies targeting .Net 1.0 and 1.1 will be 32-bit only (x86) so these assemblies will need to be upgraded to newer versions, if available, or the functionality will need to be replaced in order for the process to execute as 64-bit.

Here are some excellent links on MSDN that should be required reading before migrating a complex project to 64-bit Windows:

Visual Studio 64-bit Applications

Migrating 32-bit Managed Code to 64-bit

  • Nicely explained. I am having issues with this, and it's been driving me nuts. Cheers

  • Anki

    Can anybody tell me how we can target platforms in VS for C++ ?

  • JK

    There is one consequence of this that I just discovered. If you set the platform to x64 the imports table magically disappears from the assembly causing depends.exe to fail. This is a big problem.

  • Ted

    A note on this:

    I changed the target platform to x86 instead of "Any CPU". But, as soon as I specified a platform (x86) some namespaces/libraries/DLLs suddenly "could not be found".

    Im using MySql connector, and that works without any problems if I use "Any CPU", but if I set it to either x86 or x64 then I get this:

    The type or namespace name 'MySql' could not be found (are you missing a using directive or an assembly reference?)

    There are other DLLs that get the same error - it is NOT only MySql.

    wanted to let everyone know, I not sure at this time why this happens...

  • sada

    Is there any configuration option availabe to run an application asembly compiled with "Any CPU" platform target on x64bit machine as 32bit application?

blog comments powered by Disqus

Previous post: Visual Studio Links #61

Next post: Visual Studio Links #62