Description of Visual Studio. NET "Target Platform"

Http://blog.csdn.net/gezhaowan/article/details/6088524

The Platform target is an often overlooked option in the build configuration for Visual Studio 2005 and 2008 projects. in the "generate" configuration of Visual Studio 2005 and 2008 Projects, the "Target Platform" setting item is often ignored.

For C # projects, you will find this option on the Project Properties dialog under the build tab.

For a C # project, you will find it in the build solution under the Project Properties dialog box.

For VB.net 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.

For a VB.net project, you can find it in the advanced compilation option settings on the Compilation tab of the project properties.

The list of available options are:

The list of available options is as follows:

1. Any CPU any CPU
2. X86 x86
3. X64 x64
4. Itanium anteng

The meaning of these options is often misunderstood.

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.

According to their names, people may think that the compiler will generate different code based on the settings.

However, the C # And VB.net 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).

However, the C # And VB.net compilers use the real-time compiler to generate the Il code of Local Code only during runtime (unless ngen is used, but that is another topic ).

The fact is that this setting actually does not affect the build of the Assembly in any way doesn't to set the platform status information on the Assembly's CLR header.

In fact, this setting does not actually affect Assembly construction, but only sets the platform status information to the CLR header.

In other words, the platform target setting is meant to communicate the platform that the developer intends to be compatible.

In other words, the Platform goals are set to communicate with the Platform developers intend to be compatible.

The default setting, any CPU, means that the Assembly will run natively on the CPU is it currently running on.

By default, any CPU (any CPU) means that the Assembly runs locally and is currently running on the CPU.

Meaning, it will run as 64-bit on a 64-bit machine and 32-bit on a 32-bit machine.

That is, it runs 64-bit on a 64-bit computer and 32-bit on a 32-bit computer.

If the Assembly is called from a 64-bit application, it will perform as a 64-bit assembly and so on.

If the Assembly is called from a 64-bit application, it will be executed in a 64-bit assembly.

If the project is set to x86, this means the project is intended to run only as a 32-bit process.

If the project is set to x86, this means that the project aims to run only one 32-bit process.

A 64-bit process will be unable to call into an Assembly set as x86.

A 64-bit process cannot call an Assembly set to x86.

Reasons to set your project as x86 include dependencies upon native DLLs that are only available in 32-bit or making native callassuming 32-bit.

If your project settings have dependencies on an unmanaged DLL, you can only use 32-bit or make the assumption that the 32-bit local machine calls the local DLL.

Applications and assemblies marked for x86 can still run on 64-bit windows.

Applications and Components Marked as x86 can still run on 64-bit windows.

However they run under wow64.

However, they run in wow64.

Visual Studio itself runs under this emulation mode since it is a 32-bit application.

Visual Studio itself runs in simulation mode because it is a 32-bit application.

Setting the project to x64 will specify that the Assembly must run under 64-bit windows.

Projects set to x64 must run on 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.

An attempt to run a 32-bit Windows component or to call an assembly from a 32-bit process will cause a runtime error.

The final, and likely least common, setting is itanium.

Finally, it may be least commonly used. Set itanium.

This setting specifies that the Assembly will only run on an itanium processor.

This setting specifies that the Assembly can only run on the 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.

The only reason for setting the project as itanium is the dependency on the native DLL compiled as the itanium processor.

Developers shoshould 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.

Developers should know that simply marking the target platform of an assembly as any CPU does not guarantee that it can run on 32-bit and 64-bit windows.

In fact, since any CPU is the default setting, there are likely processing applications that actually depend upon 32-bit processing but are not marked as such.

In fact, because any CPU is the default setting, there may be many applications that actually depend on 32-bit processes, but are not marked as 32-bit.

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.

These components will fail to run in a 64-bit process on 64-bit windows. Therefore, it is important to perform Platform Testing for your application before the user is migrated to 64-bit.

The somewhat increasing popularity of Vista x64 will soon elevate the importance of this type of testing.

With the increasing popularity of Vista x64, the importance of this type of testing will soon increase.

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.

You need to know that the migration was originally developed using Visual Studio 2002 and 2003 components. . Net program to a 64-bit processor.

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. all assemblies based on 1.0 and 1.1 will be 32-bit (x86), so these components will need to be upgraded to available new versions, or functions will need to be replaced, to execute this process as 64. -Bit.

Here are some excellent links on msdn that shoshould be required reading before migrating a complex project to 64-bit windows:

Below are some excellent links on msdn that should be read before migrating a complex project to a 64-bit windows:

Visual Studio 64-bit applications

Migrating 32-bit managed code to 64-bit