In VS2017 location of Visual C++ Tools has new installation model
Now it is located somwhere like C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25203.
Or it can be for example C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017.
So full path depends on VS2017 edition and build number.
There is a macro $(VCInstallDir) which points to ..\VC** folder. But I need to know full path including part which depends on VS2017 **build number. I need this to find Visual C++ tools' include folder.
So can I determine this path without calling VS2017 Command Prompt (VCVARSALL.BAT) or PowerShell script etc.? Is thete some VS macro that I can simply put into VC++ Directory\Additional Directories property of my project?
Check out MSBuild variable $(VCToolsInstallDir), it should do the job for you. It is available in VS2017 C++ projects and its value is set to something like
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\
(depending on your tools version). Alternatively you can use $(VCInstallDir) and $(VCToolsVersion) to construct the path, but $(VCToolsInstallDir) should be more reliable.
P.S. Please note these variables only work in VS 2017 and are not available in previous versions of Visual Studio.
Related
I'm trying to add pthread library to Visual Studio 2017 (I'm using Windows 10 OS). I'm using the following guide from another post tat I saw, but I can't find the "Microsoft Visual Studio 14.0" folder in "C:\Program Files x86". I have Visual Studio 2017 and It's working. I've checked and I've installed the Visual Studio C++. What else should I install? Is there any other way to include pthread library by just adding it to the project and including the path to the library in the linker or something similar?
Thank you
Since visual studio 2017 visual studio is installed in C:\Program Files (x86)\Microsoft Visual Studio\<version>\<edition> by default e.g. C:\Program Files (x86)\Microsoft Visual Studio\2017\Community. There are other changes to the internal layout of files within the visual studio directory too. Your guide seems to only provide libraries for Visual Studio 2010 and 2012, these won't work in 2017, you should try to find an updated guide (or just use std::thread instead of pthreads).
Installing these files inside the visual studio directory isn't the right approach anyway, install them to a directory of your choice and update your project settings to point to that directory. The lazy approach in the guide is likely to cause problems in the long run.
I am using Visual Studio with C++.
For a particular reason, I now need to use CMake to build a piece of the project. I would like to tell CMake to use the same compiler I normally use with Visual Studio.
How can I find the exact cl.exe compiler executable path used by Visual Studio? There are a few of these on my machine.
Inside VS in menu Tools > Command Line select Developer Command Prompt then run where cl. You can also select Developer PowerShell and run Get-Command cl or specifically (Get-Command cl).Source
You can also open start menu, type developer and open the desired terminal
With the newer version, it probably lies in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx64\x64 or C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86 (for 32-bit). 14.26.28801 will be different in your PC though
As the question states, what is the default path to the MIDL Compiler in Visual Studio 2013 (or previous versions) for those who want to manually run it from the command line to build IDL files?
It depends on the Platform Toolset you have selected for a project. The default one (v120) takes you to c:\program files (x86)\windows kits\8.1\bin\x86\midl.exe. If you target XP (v120_xp) then you get c:\program files (x86)\microsoft sdks\windows\v7.1a\bin\midl.exe
You normally don't care and use the Visual Studio Command Prompt.
Our sources seem to expect it in Program\ Files/Microsoft SDKs/Windows/v7.0/bin/MIDL.exe so in the SDK rather than in VS. I suspect it may have been removed from the win8 sdk though when they removed the compiler. We have not yet ported to that SDK.
How can I get Visual Studio 2012 to use the native amd64 toolchain, rather than the default x86_amd64 cross-compiler?
I am building a large library that causes the linker to run out of memory when doing whole program optimization and link-time code generation.
I found two older posts (here and here) asking this same question, but no answers yet. Microsoft provides documentation on how to specify the toolchain on the command line, but not in the IDE.
There is another method of forcing use of the 64-bit linker on a per-project basis for Visual Studio 2013. Edit your .vcxproj file and insert the following after the <Import...Microsoft.Cpp.Defaults line:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
</PropertyGroup>
You need to set the environment variable "_IsNativeEnvironment" to "true" prior to starting Visual Studio 2012 IDE:
set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln
For Visual Studio 2013, the name of the environment variable is different:
set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln
Beware that this technique does not work if the version of the IDE does not match the version of the toolchain. That is, if you use VS2013 IDE configured to run VS2012 compiler, you are out of luck. But such combination is uncommon.
Here are some links for further information:
difference between VS12 and VS13
how to embed PreferredToolArchitecture into the project in VS13
If your goal is to use the native environment rather than specifically amd64_x86, you can set the UseNativeEnvironment property in your project file:
<PropertyGroup>
<UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>
(I have successfully added it to the "Globals" PropertyGroup.)
You can check which toolchain is being used by adding the /Bv compiler option. Example output is below. Notice that the toolchain directory appears after bin\ (amd64_x86 in this case).
2>ClCompile:
2> Compiler Passes:
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\CL.exe: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1xx.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c2.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\link.exe: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\mspdb120.dll: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\1033\clui.dll: Version 18.00.31101.0
I know this is a rather old post, but it's still relevant for VS 2017. Here you also have the "PreferredToolArchitecture" environment variable and a "build in" setting in the IDE is not readily available.
However you can integrate that easily on a project by project base so that you can always chose what tool architecture to use. Maybe this is helpful for some. Do this:
Go to Property Manager and create a new property sheet, e. g. named "x64 Toolchain.props" so you know what it does. With a separate property sheet you can then switch the tool architecture as appropriate by including or not including the sheet into a project.
Open the properties of that new sheet, navigate to "Common Properties\User Macros" and click "Add Macro".
In the dialog you set the name to "PreferredToolArchitecture", the value to "x64" and enable the checkbox "Set this macro as an environment variable in the build environment".
Optionally navigate to "Common Properties\C/C++\Command Line" and add "/Bv" under "Additional Options". This will make the compiler output the tools it uses including its path and version number, might be helpful for checking if really the desired architecture is being used. It will place entries in the log output window like so:
Compiler Passes:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll: Version 19.15.26730.0
Now for all projects that should be build with the x64 tool architecture include the new property sheet into the project in property manager. And for those that should not simply don't include it. That's it.
HTH
Edit:
It seems unfortunately this is not reliable! See below comments. I would really appreciate if MS would wire this setting to some GUI element and make it work consinstently...
I have a similar problem using Visual Studio 2010 on XP 64 SP2. If I set the VC++ executable directory to the amd64 bin (the native x64 folder) as the first in the search path, then I received the TRK0002 error … Invalid handle value.
But if I set _IsNativeEnvironment=true in a Visual Studio 2010 command prompt and start the ide from the command line as posted before, then the error goes away. Apparently, the 32-bit GUI IDE Environment is receiving info from a 64 bit process and is expecting info from a 32-bit process such as x86\cl.exe or x86_64\cl.exe.
In a scenario where you want to compile an IA64 bit executable, and you use the x86_ia64\cl.exe compiler. Since you are using a 32-bit cross compiler and have the _IsNativeEnvironment variable set to true, this must upset the IDE when posting messages in it's window consoles. Set the _IsNativeEnvironment=false, if you have previously set it to true.
The IDE should pick up that a native compiler was being used on a native 64-bit
machine and should have automatically set this variable to the appropriate value when the native compiler was selected from the IDE. A simple fix has never been applied to patch this problem. Solution. Do it yourself from the prompt, or buy the latest IDE from Microsoft to fix the problem.
So, the real wizards at Microsoft are the developers who work mainly from the command line. And the other developers, who wear the pointy hats and sit in the corner, must have been hired from Apple and were more concerned about appearance than function.
The whole purpose of an IDE is to make coding simple, not more complicated than using a text editor and a Makefile from the command line.
I'm trying to automate the building process for a certain open source project. It will do an update on the SVN directory, use CMake to get a .sln file, and build that. I can successfully do this manually, and do svn and cmake from a batch script, but Now I need to build the solution.
A quick google search revealed:
devenv /build release /project <projname> <solutionfile>.sln
However, that uses the latest version of visual studio (Visual Studio Professional 2011), while the .sln file generated is for Visual C++ Express 2008. I have both versions installed on my computer. Is there a devenv I can use for Visual C++ Express 2008? Or is there a commandline argument to specify which version to use?
UPDATE
I tried using msbuild, but that didn't seem to like building .vcproj files directly, and I didn't want to build ALL the project files by having it build the .sln file. I ended up using this:
"C:\Program Files\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild.exe" <myproj>.vcproj "Release|Win32"
I think you are using the wrong tool to build this. Rather than trying to drive the IDE from the command line you should simply use msbuild.
msbuild.exe projectname.proj /property:Configuration=Release
In order to set your environment up for the specific version of MSVC you need to call the vcvar.bat file from that specific version. This will set up the necessary environment variables needed by the build tools.
For Visual Studio Express 2008 the IDE is called VCExpress.exe. Also you should probably specify the full path of the program when you have two versions installed:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\VCExpress.exe /build release /project <projname> <solutionfile>.sln