Console App Platform always "Active(x86)"

Question

If I go to project properties of a C# Console Application, its Platform is always set to Active(x86) where Platform target is x64, as shown in the img:

Can somebody tell what's the difference and how to create an app whose Platform is x64.

Answer 1

Microsoft made a couple of drastic design mistakes in VS2010, this is one of them. The Platform name for managed projects always used to be "AnyCPU". It is again in V2012 and up. But the default name in VS2010 is "x86".

That was a horrible choice, given that the Platform name is completely irrelevant to a managed project. Managed code runs on any platform, it is the Just-In-Time compiler that automatically converts the MSIL that the compiler generates to machine code. At runtime, not build time. So "AnyCPU" is a much more descriptive name, the jitter truly does make it run on "any cpu".

This momentary lapse of good thinking was induced by a significant change in the C++ project build model. VS2010 is the first version of Visual Studio where C and C++ projects are built with MSBuild instead of the custom build engine (VCBuild) used in previous versions. The Project selection is a Really Big deal for such projects, it selects the compiler that's used to compile the source code. Different cpus require different compilers because C++ code is directly translated into machine code.

So just ignore this, the name just doesn't matter. And above all, it has no effect at all on what the jitter does. Which requires a different setting if you want to force it to only generate 32-bit code. You found the setting that does that.

Answer 2

The platform refers to if you want to compile/build the project on x86 which is 32Bit architecture or x64 which is 64 Bit architecture. 64 bit app will run on 64 bit architecture, while 32 bit app can run on 64/32 Bit architecture,

regarding how to create an x64 app, you just choose x64 in your configuartion manager. refer to the following documnet for detailed explaination http://visualstudiohacks.com/articles/visual-studio-net-platform-target-explained/

Answer 3

Ok, Sorry in advance for the length of this answer but your question very neatly scratches on the surface of quite a lot of complexity.

Producing assemblies and native code

From the bottom up, Visual Studio/MSBuild do not produce the code that finally runs on machines that run your code. Instead they produce an assembly full of MSIL (MicroSoft Intermediary Language) which is translated at run time by CLR into native code for that machine. For assemblies that you use regularly the machine can also cache the native code in advance by using NGEN.

Every assembly can have a platform target. As Hans points out this doesn't actually do very much other than identify to the jitter what flavour your native code should be in. This indication is just a couple of bytes in the header of your assembly, and can actually be changed post-msbuild by using the corflags tool. Don't worry you don't need to ever use this. Normally during the build process, msbuild/VS will look at the platform target for each project and produce an assembly with the correct header.

Run time consumption of assemblies

Let's consider what happens when you now run your complied assembly. First, Windows identifies it as DotNet from its header and uses the CLR as a host environment for it. That environment will vary due to the version of DotNet, e.g. 2.0, 4.0, 4.5 etc and also for 32 or 64 bit. The environment will then start generating native runnable code from your MSIL assembly and start executing it.

Now all applications then call into other assemblies (at least System/mscorlib). The CLR will do its best to ensure that the correct version of these is loaded in. This can be from the their installed location (e.g. C:\Windows\Microsoft.Net\Framework...), the GAC (including NGEN versions), or from the applications current directory (see How the runtime locates assemblies). Sometimes this process will fail, because for example it can't find a required version of an assembly (i.e. can only find v1.0 when it needs v2.0) or it finds a 64bit when it needs a 32bit.

Producing applications

Back in Visual Studio there is something that most people miss. It's called configuration manager and its hidden on the bottom of the Solution Configurations dropdown in the Standard toolbar.

It basically provides us with a way to select the various flavours of attributes for all the assemblies we are building. For example here is a default Debug AnyCPU build.

At the top of the dialog there are two drops downs, the 2nd one lets you select the Active Platform.

But no-one knows about configuration manager

I assume the problem is most people don't know about this dialog and so instead if they want to create a 64bit build they will usually go into each project and change the AnyCPU build over to x64. In the past 10 yrs, I have never yet come across a code base that supports 64bit where somebody hasn't done this.

Also note, there is a special configuration that can appear called Mixed Platforms. It is supposed to handle a solution where you either have a native (e.g. C++) assembly as well as your DotNet, or when you are targetting multiple platforms such as Phone and Desktop. It can also get produced if you mix up your 32bit, 64but and AnyCPU etc.

Recommendations

Instead I recommend you do the following,

• Go into configuration manager and remove all platform configurations that you aren't using. Ideally pare it back to just Debug and Release for AnyCPU. Use the Edit... on the drop downs then select and hit Remove.
• Create a new Platform by selecting New... from the platform drop down. Copy it from AnyCPU.

• Now for the fun bit, go through every project you have, and for each Platform ensure that it is building the correct Platform target.

And finally, Building

You can now build your codebase in one of three ways

• Use the configuration manager to switch your active platform and press F5.
• Use the Batch Build dialog (bottom of the Build Menu) to build the platforms you want to build.
• Or use the devenv command line devenv.com myApp.sln /build "Debug|AnyCPU"