Since cpptools 1.29.2
Courtesy of cpptools PR 13571, you can (purportedly) use the Set Visual Studio Developer Environment command to pick an MSVC toolset to be used for compilation, within any new terminals launched in the current VS Code session's current workspace.
Pre cpptools 1.29.2 / elaboration
Read the docs for configuring VS Code for Microsoft C++.
The following excerpt is found under a screenshot showing the following error:
"cl.exe build and debug is only usable when VS Code is run from the Developer Command Prompt for VS."
If you get an error trying to build and debug with cl.exe, make sure you have started VS Code from the Developer Command Prompt for Visual Studio using the
code .shortcut.
Each version of Visual Studio Build Tools come with a developer prompt that sets up an environment for using that version's tools. For example, it puts directories in its evironment's PATH so that they can be easily accessible. Some other tools like VS Code in configurations that use Visual Studio Build Tools may expect to be run from that environment.
There's some good related info in https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line#how-to-use-the-command-line-tools :
To work correctly, the tools require several specific environment variables to be set. These variables are used to add the tools to the path, and to set the locations of include files, library files, and SDKs. To make it easy to set these environment variables, the installer creates customized command files, or batch files, during installation. You can run one of these command files to set a specific host and target build architecture, Windows SDK version, and platform toolset. For convenience, the installer also creates shortcuts in your Start menu. The shortcuts open developer command prompt windows by using these command files for specific combinations of host and target. These shortcuts ensure all the required environment variables are set and ready to use.
The required environment variables are specific to your installation and to the build architecture you choose. They also might be changed by product updates or upgrades. This variability is one reason why we recommend you use an installed command prompt shortcut or command file, instead of setting the environment variables yourself.
It can be a pain to do this dance when launching VS Code, but I don't see how this could be improved if you have multiple Visual Studio installations and want to develop in VS Code using a particular one's build tools.
If you don't care to have the entire VS Code process started with an environment from a VS developer prompt, and you only care that a build task you've defined in tasks.json will work, and you are okay with hardcoding a specific developer prompt environment for the workspace, you can follow the instructions in https://code.visualstudio.com/docs/cpp/config-msvc#_run-vs-code-outside-the-developer-command-prompt. Read the docs for the full info and caveats, but TL;DR, put something like the following (adjust as needed) at the top-level of your tasks.json:
"windows": { "options": { "shell": { "executable": "cmd.exe", "args": [ "/C", // The path to VsDevCmd.bat depends on the version of Visual Studio you have installed. "\"C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/VsDevCmd.bat\"", "&&" ] } } },
There are other tricks you can probably experiment with. See https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line#developer_command_file_locations, which gives the locations of the command files that you can use to modify the environment of an existing command prompt instead of using one of the pre-built developer command prompts. For example, writing a script file that just runs one of those command files to set up a chosen developer environment, and then run code, passing through the rest of the commandline arguments to code. Then you could pin that script file to some easy-to-reach location, or use it via commandline. For example, see Run VScode from Dev Console through Context Menu.
See also How to permanently configure VSCode to use cl.exe without launching it from the Developer Command Prompt?.
Note that if you're using CMake, the CMake Tools extension has a "kits" feature (see also What are the differences between the scanned-for kits on my Windows machine using the VS Code cmake-tools extension?) and supports CMake presets, both of which have mechanisms for handling this kind of stuff (for presets, see the "architecture" and "toolset" properties of configure presets).
Answer from starball on Stack OverflowSince cpptools 1.29.2
Courtesy of cpptools PR 13571, you can (purportedly) use the Set Visual Studio Developer Environment command to pick an MSVC toolset to be used for compilation, within any new terminals launched in the current VS Code session's current workspace.
Pre cpptools 1.29.2 / elaboration
Read the docs for configuring VS Code for Microsoft C++.
The following excerpt is found under a screenshot showing the following error:
"cl.exe build and debug is only usable when VS Code is run from the Developer Command Prompt for VS."
If you get an error trying to build and debug with cl.exe, make sure you have started VS Code from the Developer Command Prompt for Visual Studio using the
code .shortcut.
Each version of Visual Studio Build Tools come with a developer prompt that sets up an environment for using that version's tools. For example, it puts directories in its evironment's PATH so that they can be easily accessible. Some other tools like VS Code in configurations that use Visual Studio Build Tools may expect to be run from that environment.
There's some good related info in https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line#how-to-use-the-command-line-tools :
To work correctly, the tools require several specific environment variables to be set. These variables are used to add the tools to the path, and to set the locations of include files, library files, and SDKs. To make it easy to set these environment variables, the installer creates customized command files, or batch files, during installation. You can run one of these command files to set a specific host and target build architecture, Windows SDK version, and platform toolset. For convenience, the installer also creates shortcuts in your Start menu. The shortcuts open developer command prompt windows by using these command files for specific combinations of host and target. These shortcuts ensure all the required environment variables are set and ready to use.
The required environment variables are specific to your installation and to the build architecture you choose. They also might be changed by product updates or upgrades. This variability is one reason why we recommend you use an installed command prompt shortcut or command file, instead of setting the environment variables yourself.
It can be a pain to do this dance when launching VS Code, but I don't see how this could be improved if you have multiple Visual Studio installations and want to develop in VS Code using a particular one's build tools.
If you don't care to have the entire VS Code process started with an environment from a VS developer prompt, and you only care that a build task you've defined in tasks.json will work, and you are okay with hardcoding a specific developer prompt environment for the workspace, you can follow the instructions in https://code.visualstudio.com/docs/cpp/config-msvc#_run-vs-code-outside-the-developer-command-prompt. Read the docs for the full info and caveats, but TL;DR, put something like the following (adjust as needed) at the top-level of your tasks.json:
"windows": { "options": { "shell": { "executable": "cmd.exe", "args": [ "/C", // The path to VsDevCmd.bat depends on the version of Visual Studio you have installed. "\"C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/VsDevCmd.bat\"", "&&" ] } } },
There are other tricks you can probably experiment with. See https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line#developer_command_file_locations, which gives the locations of the command files that you can use to modify the environment of an existing command prompt instead of using one of the pre-built developer command prompts. For example, writing a script file that just runs one of those command files to set up a chosen developer environment, and then run code, passing through the rest of the commandline arguments to code. Then you could pin that script file to some easy-to-reach location, or use it via commandline. For example, see Run VScode from Dev Console through Context Menu.
See also How to permanently configure VSCode to use cl.exe without launching it from the Developer Command Prompt?.
Note that if you're using CMake, the CMake Tools extension has a "kits" feature (see also What are the differences between the scanned-for kits on my Windows machine using the VS Code cmake-tools extension?) and supports CMake presets, both of which have mechanisms for handling this kind of stuff (for presets, see the "architecture" and "toolset" properties of configure presets).
The error message is somewhat misleading. It really means that a few important environment variables haven't been set. I regularly invoke cl from a cygwin bash, for example -- I use a small bash function to do this:
cl_x86_64() {
export INCLUDE='C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\um;C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\shared;C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\winrt;C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\cppwinrt'
export LIB='C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\ATLMFC\lib\x64;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\lib\x64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.22621.0\ucrt\x64;C:\Program Files (x86)\Windows Kits\10\\lib\10.0.22621.0\\um\x64'
export LIBPATH='C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\ATLMFC\lib\x64;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\lib\x64;C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\lib\x64\store\references;C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.22621.0;C:\Program Files (x86)\Windows Kits\10\References\10.0.22621.0;C:\Windows\Microsoft.NET\Framework\v4.0.30319'
/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio/2022/Community/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe "$@"`
}
If you're working from a Windows cmd or powershell, of course, the syntax will be different, but you get the idea.
And the contents of the variables will depend one how you're compiling and where Visual Studios was installed. My suggestion here is to invoke the developer command prompt once, and copy these three variables from it. (Of course, if you're happy using cmd, that's actually what you get when you invoke the developer command prompt from Visual Studios, so you really don't need anything else.)
Whenever I try to run my code in visual studio at the corner of my screen it says "click.exe build and debug is only usable when VS code is run from Developer Command Prompt for VS" wtf does this mean??? 😭😭
cpp
Microsoft C++ configure "Run VS Code outside the Developer Command Prompt" doesn't work
c - How to permanently configure VSCode to use cl.exe without launching it from the Developer Command Prompt? - Stack Overflow
Hot Linked Questions - Stack Overflow
As I was writing this question I finally found the solution, so I decided to share it here. I tried to make it beginner friendly (win10 - x64).
Steps (for x64):
Locate and copy x64
cl.exe's location, usually at:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\[version]\bin\Hostx64\x64Press Win+R to open Run dialog and type
sysdm.cplto get System PropertiesGo to
AdvancedTabClick on
Environment VariablesIn
System variablessection locatePathvariable and double click itOn the new window that pops up click
Newand addcl.exe's locationClick
OK
Now we still have to add the VARS that are setup when you run Developer Command Prompt for VS YYYY:
Open
x64 Native Tools Command Prompt for VS YYYY. It has to bex64or else you'll get alibrary machine type 'x86' conflicts with target machine type 'x64'error when compiling.cdto your preferred directory as we are going to create a fileRun
set > envvars.txtOn this new file
envvars.txtfind these 3 lines:a)
INCLUDE=C:\...
b)LIB=C:\...
c) andLIBPATH=C:\...and delete everything else.
Now there are 2 ways to add these VARS to the System variables manually or through a one-time *.bat file. I chose the *.bat file way:
We are going to turn
envvars.txtinto this*.batfile by:a) Preceding each of the vars by
setx(permanently setting environment variables)b) Replacing the
=with a spacec) involving the paths with quotation marks
""d) adding
/Mafter the paths on each line (ensures that the variables are set for the system and not just the current user)We should have something like:
setx INCLUDE "C:\Program Files\..." /M setx LIB "C:\Program Files\..." /M setx LIBPATH "C:\Program Files\..." /MRename
envvars.txttoenvvars.batExecute as Administrator
Restart computer
Done.
After restart you should be able to launch VS Code however and just compile and debug. (ASSUMING YOUR TASKS.JSON AND LAUNCH.JSON are setup properly)
I did find a workaround that is quite comfortable to use. You can create bat file that launches the vs code through Developer Command prompt. First you create bat file containing this:
@echo off
REM (your ardess to VsDevCmd.bat)
call "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\VsDevCmd.bat"
start code "C:[path to desired folder]"
This will automatically start vs code in mode that has access to cl.exe
If you don´t want the leftover command prompt you can automatically close it only by putting
taskkill /F /IM "cmd.exe" /T at the end of the VsDevCmd.bat file
If you then create shortcut to this bat file and put Explorer.exe you can even pin it to your taskbar.
Please correct any part I'm wrong.
Screenshots:
https://imgur.com/a/Rh9LHIv
Building: Please refer to figure 1
When building, a menu of cl.exe, cpp.exe, and g++.exe compilers shows up for the users to choose.
Debugging (where building is part of the process): Please refer to figure 2.1 and 2.2
When building, a menu of GDB/LLDB and windows debuggers show up for the user to choose. After choosing one of the debuggers,
another menu of g++.exe and cpp.exe compilers show up.
First, I don't understand why when you build then debug, the second menu of of g++.exe and cpp.exe compilers show up. I already chose the compiler when building. Is this just design choice by the visual studio developers to give the users choice to choose different compiler when building v.s. when debugging?
Second, why does cl.exe (C++ compiler) show up when building but doesn't show up when debugging? Doesn't debugging encompasses building process as well, and therefore, should give you the same choice of compilers when building?