How to make Visual Studio 2012 call the native 64-bit Visual C++ compiler instead of the 32-bit x64 cross-compiler?

Question

Visual Studio 2012 seems to always call the 32-bit version of cl.exe located at %ProgramFiles(x86)%\\Microsoft Visual Studio 11.0\\VC\\bin\\x86_amd64)

Answer 1

This answer is a bit late to the party, but frustratingly there's still no good resource directly available from Microsoft's online documentation. It turns out to be easy, even if not totally convenient.

At the command prompt, type (changing the version of VS to your needs):

> set _IsNativeEnvironment=true
> "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" YourProject.sln

The clue for this is in the file

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.targets

where it says

<SetEnv Condition="'$(_IsNativeEnvironment)' == 'true'"
        Name ="PATH"
        Value ="$(NativeExecutablePath)"
        Prefix ="false">
  <Output TaskParameter="OutputEnvironmentVariable" PropertyName="Path"/>
</SetEnv>

My project is generated by CMake, so I am usually at the command prompt for a few lines before I can open VS anyway. I have always started my CMake generators after first setting up the MSVC environment, so I honestly don't know if it's required or not, but you can optionally also do (before everything else):

> call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" amd64

and /or

> call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\vcvars64.bat"

Here's the link to the original post on MSDN where I finally found the answer.

Answer 2

I was converting an old project from Win32 to x64 and came across this problem.
I found two different ways on how to go around this:

Method 1:
i. Got to: Project properties | General | Platform Toolset
ii. Change the value from 'Visual Studio 2012 (v110)' to 'Visual Studio 2012 - Windows XP (v110_xp)'

Mehtod 2:
i. Open configuration file %LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
ii. Inside the <ExecutablePath> property group, I replaced the $(WindowsSDK_ExecutablePath_x64) entry with $(WindowsSDK_ExecutablePath_x86)

After any of these all worked fine.