Where are the x64 and ARM Developer Prompts for VS2017? - visual-studio

I installed the Visual Studio 2017 Build Tools. After installation, there's only an x86 Developer Command Prompt when navigating Start → Programs → Visual Studio 2017 → Visual Studio Tools. There are no prompts for x64 and ARM. (Usually there's about 6 developer prompts to choose from).
Where are the build tools for x64 and ARM located?
UPDATE (JAN-18-2017)
After installing the entire Windows 10 SDK, Build 15003 per #magicandre1981 instructions, I cannot find the Developer Prompts. I can't find them in the Start menu; and dropping into a Git Bash shell and searching for them returns 0 results.
In the names below, vsdevcmd.bat is what was installed by the VC++ Build Tools for 2017. vcbuildtools.bat is what was installed by the VC++ Build Tools for 2015.
MINGW64 /c/Program Files (x86)/Windows Kits/10
$ find . -iname 'vsdevcmd.*'
$ find . -iname 'vcbuildtools.*'
$ find . -iname '*.bat'
$ find . -iname '*.cmd'
./bin/10.0.15003.0/arm/SecureBoot/DeleteKitsPolicy.cmd
./bin/10.0.15003.0/arm/SecureBoot/InstallKitsPolicy.cmd
./bin/10.0.15003.0/arm64/install-sampleprovider.cmd
./bin/10.0.15003.0/arm64/uninstall-sampleprovider.cmd
./bin/10.0.15003.0/x64/install-sampleprovider.cmd
./bin/10.0.15003.0/x64/uninstall-sampleprovider.cmd
./bin/10.0.15003.0/x86/DismFoDInstall.cmd
./bin/10.0.15003.0/x86/GenerateUnionWinMD.cmd
./bin/10.0.15003.0/x86/install-sampleprovider.cmd
./bin/10.0.15003.0/x86/uninstall-sampleprovider.cmd
./bin/arm/SecureBoot/DeleteKitsPolicy.cmd
./bin/arm/SecureBoot/InstallKitsPolicy.cmd
./bin/arm64/install-sampleprovider.cmd
./bin/arm64/uninstall-sampleprovider.cmd
./bin/x64/install-sampleprovider.cmd
./bin/x64/uninstall-sampleprovider.cmd
./bin/x86/DismFoDInstall.cmd
./bin/x86/GenerateUnionWinMD.cmd
./bin/x86/install-sampleprovider.cmd
./bin/x86/uninstall-sampleprovider.cmd
./Debuggers/x64/srcsrv/cv2http.cmd
./Debuggers/x64/srcsrv/cvsindex.cmd
./Debuggers/x64/srcsrv/p4index.cmd
./Debuggers/x64/srcsrv/ssindex.cmd
./Debuggers/x64/srcsrv/svnindex.cmd
./Debuggers/x64/srcsrv/tfsindex.cmd
./Debuggers/x64/srcsrv/vssindex.cmd
./Debuggers/x64/srcsrv/walk.cmd
./Debuggers/x86/srcsrv/cv2http.cmd
./Debuggers/x86/srcsrv/cvsindex.cmd
./Debuggers/x86/srcsrv/p4index.cmd
./Debuggers/x86/srcsrv/ssindex.cmd
./Debuggers/x86/srcsrv/svnindex.cmd
./Debuggers/x86/srcsrv/tfsindex.cmd
./Debuggers/x86/srcsrv/vssindex.cmd
./Debuggers/x86/srcsrv/walk.cmd
./Windows Performance Toolkit/gpuview/log.cmd
./Windows Performance Toolkit/gpuview/log_mem.cmd
./Windows Performance Toolkit/WdfPerfEnhancedVerifier.cmd
$
Out of desperation, I copied the 2017 Build Tools Developer Prompt (for x86), and added the amd64_arm as the 2015 build tools does. It results in a failure:
[ERROR:parse_cmd.bat] Invalid command line argument: 'amd64_arm'. Argument will
be ignored.
**********************************************************************
** Visual Studio 2017 RC Developer Command Prompt v15.0
** Copyright (c) 2016 Microsoft Corporation
**********************************************************************
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be inc
omplete and/or incorrect. ***
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools>
More desperation... I started tracing the msiexec installers using process monitor, and examining MSI contents using 7-zip. The best I can tell, there are no developer prompts, even in the Developer Tools MSI installer:

The developer prompt bat files seem to have been restructured a little in VS 2017. Instead of having a fixed set of predefined developer prompts, you can customize it even more now.
To get a developer prompt for e.g. arm, add -arch=arm -host_arch=amd64 as parameters to VsDevCmd.bat (e.g. in the shortcut in the start menu).
For the full list of available options, have a look in \Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\vsdevcmd\core\parse_cmd.bat, or call "\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\vsdevcmd" -help.
I'm not sure if this really is documented anywhere, or if it will be fixed up and/or documented better for the final release of VS 2017.
Installing the insider preview Windows 10 SDK is unrelated to this; the standalone Windows SDK doesn't include any compilers, only headers and link libraries.

Install the Windows 10 SDK and WDK (at least Build 16299) to get the ARM Compiler for Desktop Applications.
Open the Project configuration and create ARM(64) configuration:
If you try to compile it you would get an error that ARM64 is not supported for Desktop:
To fix this, unload the project and open it in editor and add the line <WindowsSDKDesktopARM64Support>true</WindowsSDKDesktopARM64Support> to the debug and release entry for ARM64:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>true</UseDebugLibraries>
<PlatformToolset>v141</PlatformToolset>
<CharacterSet>Unicode</CharacterSet>
<WindowsSDKDesktopARM64Support>true</WindowsSDKDesktopARM64Support>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|ARM64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<PlatformToolset>v141</PlatformToolset>
<WholeProgramOptimization>true</WholeProgramOptimization>
<CharacterSet>Unicode</CharacterSet>
<WindowsSDKDesktopARM64Support>true</WindowsSDKDesktopARM64Support>
</PropertyGroup>
and WindowsSDKDesktopARMSupport for 32Bit ARM.
Save changes, load the project again and now compilation works fine:
The 15.9 Update for VS2017, adds official ARM64 support (only for UWP), here the commandline to open ARM64 dev prompt is:
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" amd64_arm
32 Bit Arm commandline is:
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" x86_arm

Related

QT - Set windows platform version

I updated my Windows version to 10.0.15063.0 and every lib is missing, so I had to change the platform version to 10.0.14393.0 on Visual Studio, is there any equivalent for QT? The reason I ask is because QT seems to be using the 10.0.15063.0 version and so I get errors like kernel.lib / shell32.lib are missing, etc.
Option 1
You need to install the Windows 10 SDK for 10.0.15063.0
If you have Visual Studio 2017 installed this can be done by using the "Visual Studio Installer". In "Individual components", check "Windows 10 SDK (10.0.15063.0) for Desktop C++ x86 and x64" and apply the changes.
Option 2
Command line
If you build your project from the command line you can specify which Windows kit you want to use when calling vcvarsall.bat
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 10.0.14393.0
Qt Creator
If you use Qt Creator, the call to vcvarsall.bat is made automatically. You can see the call in Qt Creator settings in "Build & Run" > "Compilers".
However the GUI does not provide a mean to add extra arguments to the command line.
You might be able to force the arguments by editing C:\Users\<username>\AppData\Roaming\QtProject\qtcreator\toolchains.xml. This file should contains something like:
<value type="QString" key="ProjectExplorer.MsvcToolChain.VarsBat">C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat</value>
<value type="QString" key="ProjectExplorer.MsvcToolChain.VarsBatArg">x86</value>
You could change it to:
<value type="QString" key="ProjectExplorer.MsvcToolChain.VarsBat">C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat</value>
<value type="QString" key="ProjectExplorer.MsvcToolChain.VarsBatArg">x86 10.0.14393.0</value>
But keep in mind that you are not supposed to edit this file by hand and it may or may not work.

CMake -G Ninja on Windows specify x64

I am using CMake on Windows with Ninja generator
cmake -G Ninja ..
This uses the default Windows x86 toolchain.
How to specify x64 using the Ninja generator?
PS: I know how to generate x64 with Visual Studio
cmake -G "Visual Studio 12 2013 Win64 ..
You have to set the compiler environment accordingly before calling Ninja generation. If you have Visual Studio 2013 installed at the standard installation path you call:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x64
cmake.exe -G "Ninja" ..
Edit: Thanks for the hint from #Antwane: "Or simply run CMake command from a Microsoft Visual Studio Command Prompt (x64). A shortcut to this prompt is located in Start Menu".
The naming varies over the Visual Studio versions:
When I then look into the generated CMakeCache.txt file I see:
...
//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe
...
//Flags used by the linker.
CMAKE_EXE_LINKER_FLAGS:STRING= /machine:x64
...
//Path to a program.
CMAKE_LINKER:FILEPATH=C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/link.exe
...
When I tried to run cmake on command line in Windows, trying to use Ninja and targetting the Visual Studio 14.0 compiler (2015), it kept picking up on other installed compilers (in my case gcc) instead.
The following command line worked:
cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER="cl.exe" -DCMAKE_CXX_COMPILER="cl.exe" -DMSVC_TOOLSET_VERSION=140 ..
This answer assumes you have Visual Studio installed and have installed all the proper C++ libraries and what not when you installed visual studio.
Start typing in "x64 Native Tools" in your start menu. Open the file location and you will see a certain amount of shortcuts. On my visual studio installation I only have compilers for the x86/x64 architecture.
Anyway now that you have opened the file location you will be presented with a bunch of developer command prompt shortcuts:
PS C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2019\Visual Studio Tools\VC> ls
Directory: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2019\Visual Studio Tools\VC
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/16/2021 8:12 PM 2139 x64 Native Tools Command Prompt for VS 2019 Preview.lnk
-a--- 2/16/2021 8:12 PM 2197 x64_x86 Cross Tools Command Prompt for VS 2019 Preview.lnk
-a--- 3/3/2021 9:01 PM 2139 x86 Native Tools Command Prompt for VS 2019 Preview.lnk
-a--- 2/16/2021 8:12 PM 2197 x86_x64 Cross Tools Command Prompt for VS 2019 Preview.lnk
PS C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2019\Visual Studio Tools\VC>
Let me explain what each one does:
x64 Native Tools Command Prompt for VS 2019 Preview
Use x64 compiler to compile for a x64 machine
x64_x86 Cross Tools Command Prompt for VS 2019 Preview
Use x64 compiler to compile for a x86 machine
x86 Native Tools Command Prompt for VS 2019 Preview
Use x86 compiler to compile for a x86 machine
x86_x64 Cross Tools Command Prompt for VS 2019 Preview
Use x86 compiler to compile for a x64 machine
In my opinion the last 2 are useless in the modern day. And have caused multiple CI crashes on our servers. So we only use 64 bit binaries.
Anyway you double click on one of the shortcuts:
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.10.0-pre.1.0
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview>
And bang you will have a command prompt loaded with an environment CMake can recognize. This is because the PATH environment variable now contains the compilers and what not.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview>echo %PATH%
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\\Extensions\Microsoft\IntelliCode\CLI;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.29.29917\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\bin\Roslyn;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Team Tools\Performance Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Team Tools\Performance Tools;C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\vs2019\\x64;C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\vs2019\;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\Tools\devinit;C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\\MSBuild\Current\Bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\Tools\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\LLVM\bin;C:\Program Files\Git\cmd;C:\Program Files\PowerShell\7\;C:\Program Files\CMake\bin;D:\Installations\Python\Scripts\;D:\Installations\Python\;C:\Users\juanr\AppData\Local\Microsoft\WindowsApps;D:\Installations\Microsoft VS Code\bin;C:\Users\juanr\AppData\Local\GitHubDesktop\bin;D:\Git\ninja;;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\Llvm\x64\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja
Now you can run cmake with Ninja:
NOTE: In this example I'm manually specifying the path to Ninja. You can also just add Ninja to your path. And depending on your visual studio installation this may already be done for you. If you download the "C++ CMake tools for Windows" you have Ninja added to your path for you. You even get CMake added for you.
cmake -S . -B build -G "Ninja" -DCMAKE_MAKE_PROGRAM=C:/foobar/ninja.exe

What's the difference between various command shells in VS2010?

What's the difference between "visual studio x64 win64 command prompt", "visual studio x64 cross tools command prompt", and "visual studio command prompt" appearing in the Visual Studio 2010 menu in the Start button?
For the most useful answer, let us be clear about my ignorance level: I'm closer to noob than guru at anything Microsoft or IDEs in general. Long time expert at Linux, editing source in a plain text editor, handmade Makefiles, etc.
I'm sure the differences are simple, perhaps "obvious" to anyone with modest experience at VS2010.
The different batch files adjust PATH, LIB, INCLUDE and LIBPATH so that you can run cl.exe and other build tools easily.
This answer focuses mostly on VS2013. Microsoft's documentation http://msdn.microsoft.com/en-us/library/ms229859%28v=vs.110%29.aspx states:
Starting with Visual Studio 2010, you may see multiple command prompts, depending on the version of Visual Studio and any additional SDKs you've installed. For example, 64-bit versions of Visual Studio provide both 32-bit and 64-bit command prompts. (The 32-bit and 64-bit versions of most tools are identical; however, a few tools make changes specific to 32-bit and 64-bit environments.)
It adds, rather unhelpfully:
Check the documentation for the individual tools to determine which version of the command prompt you should use.
The page http://msdn.microsoft.com/en-us/library/jj153218.aspx lists five such command prompts:
Developer Command Prompt for VS2013
VS2013 ARM Cross Tools Command Prompt
VS2013 x64 Cross Tools Command Prompt
VS2013 x64 Native Tools Command Prompt
VS2013 x86 Native Tools Command Prompt
On my machine, only the 1st, 3rd, and 5th of these are present, and they launch, respectively:
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat""
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"" x86_amd64
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"" x86
To check the environment variables, running the set command for first and "x86 Native" shells gives identical results on my machine. And mmohamad's answer tp Difference between VsDevCmd.bat & vcvarsall.bat in VS2012 agrees with this.
But "x64 Cross" is different: the difference is (excluding Path and LIBPATH for brevity):
+ CommandPromptType=Cross
+ FrameworkDIR64=C:\WINDOWS\Microsoft.NET\Framework64
+ FrameworkVersion64=v4.0.30319
+ Platform=x64
- LIB=C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86;
+ LIB=C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB\amd64;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64;

visual studio 2010 express + win sdk = cannot open input file 'kernel32.lib'

I used to compile for x64 using VS2008 express and win SDK. Recently rebuilt my machine (upgraded to 64bit Windows 7) and got latest express installed. Followed the same procedure to allow x64 targets and my sources don't link any more.
no matter what I do I always get:
LINK : fatal error LNK1181: cannot open input file 'kernel32.lib'
funny enough 32bit compilation works fine.
Is this some well know problem? Google didn't give me any clues how to tackle it just a couple of mentions of the same problem but no solutions.
Is it possible to use VS 2010 with win 7 SDK to target 64bit?
thanks
Pawel
the solution was dead easy at the end. The trick is to point VS to win SDK that for some reason was incorrect in my case.
Project Properties -> VC++ Directories -> Library Directories should point to C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64
Something else I found, also dead easy, is to go to Project Properties->General and set Platform Toolset to Windows7.1SDK. Wonder why this works...
I've had the same problem and the answers here helped me, but I had to do more things.
Something had corrupted my Windows SDK installation, so I was missing all .lib files that go into C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\ (the x64 folder inside was ok). So I followed what's been said here and reinstalled it. Than I could set Platform Toolset to Windows7.1SDK (in both VS2010 and VS2013).
This works because the Platform Toolset changes the $(WindowsSdkDir) path within Visual Studio (those paths saved are in the system registry), which were broken if Kernel32.lib isn't found.
If none of the above solutions worked. Stop and do a sanity check. I got burned using the wrong -G config string and it gave me this misleading error.
First, run from the VS Command Prompt not the regular command prompt. You can find it in
Start Menu -> Visual Studio 2015 -> MSBuild Command Prompt for VS2015
This sets up all the correct paths to VS tools, etc.
Now see what generators are available from cmake...
cmake -help
...<snip>...
The following generators are available on this platform:
Visual Studio 15 [arch] = Generates Visual Studio 15 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
Optional [arch] can be "Win64" or "IA64".
...
Then chose the appropriate string with the arch added.
mkdir _build
cd _build
cmake .. -G "Visual Studio 15 Win64"
Running cmake in a subdirectory makes it easier to do a 'clean' since you can just delete everything in that directory.
I upgraded to Visual Studio 15 but wasn't paying attention and was trying to generate for 2012.
FWIW, I had the same problem with Visual Studio 2013 when the entire v8.1 SDK install (files + reg keys) went AWOL, probably caused by the installation of Emborlandero RAD Studio.
Setting the WindowsSdkDir environment variable had no effect since both Studio itself (devenv.exe, environment inspected via Process Explorer) and a batch file called from a batch file called from vcvarsall.bat effectively erased that variable because they couldn't find the v8.1 SDK.
Visual Studio doesn't allow machine-specific directories to be configured in a machine-wide way (the suggestion to put this machine dependency into each and every project file is ludicrous beyond belief) and re-installing the v8.1 SDK was not possible in a timely fashion. A quick fix to get Studio working again in the meantime was to add the string value InstallationFolder under
Software/Microsoft/Microsoft SDKs/Windows/v8.1/
with the same contents as its v8.0 cousin. This was under HKLM/Wow6432Node but plain HKLM or HKCU should work as well.
That got Studio working again immediately, without even a restart.

Visual Studio Command Prompt vs. a regular command prompt?

When I open a Visual Studio command prompt (for example, opened with menu Start -> Programs -> Microsoft Visual Studio 2008 -> Visual Studio Tools -> Visual Studio 2008 Command Prompt), I get:
Setting environment for using Microsoft Visual Studio 2008 x86 tools.
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE>
What kind of tools are available, and what are the most common uses of this command prompt?
It basically just sets several of the Visual Studio binary locations into the PATH environment variable for that command window instance. This means you can use all the various commands and tools without having to include the full paths.
There's a partial list of some of the tools available on MSDN in .NET Framework Tools and Tools (.NET Framework).
The Visual Studio command prompt is a convenient way to access the command line tools that ship with the .NET Framework SDK and, if installed the, Windows Platform SDK tools.
By providing the Visual Studio command prompt, Microsoft allows you to run these tools without requiring your PATH, INCLUDE, LIB and LIBPATH environment variables to contain all the additional paths to the various folders where Visual Studio and the .NET SDK are installed. Instead, these folder references are added on the fly when you start the Visual Studio command prompt allowing you to run the tools.
For example, if you open a regular command prompt you cannot run xsd.exe without changing to the directory "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin". However, in the Visual Studio command prompt you can just type xsd.exe /?, and it works.
Please see the MSDN article .NET Framework Tools for a complete list of the tools provided with Visual Studio 2008 SP1 and details on what they do.
The Visual Studio command prompt has a few tools with it. Some tools are for repairing the install of Visual Studio. One of the tools I love using is for WCF. You type wcftestclient and you get a client to test your WCF services.
The article The Visual Studio Command Prompt has a nice explanation:
Let's look at the "Visual Studio Command Prompt" in more detail.
It appears to just set the path for you and put you in (Ta Da!) the VC
directory under Visual Studio. Not even the C# directory and certainly
not the VB directory. I guess they assume that anyone who uses this
tool is really hard core and programs directly against the hard drive
with a magnifying glass and a magnet.
What it actually does is run this DOS command. (In my case.)
%comspec% /k ""C:\Program Files\Microsoft Visual Studio
10.0\VC\vcvarsall.bat"" x86
What does vcvarsall.bat do? Well, it sets the target compiler
environment so you can compile code for a different processor.
One use seems to be to call the XML Class Generator for using XSD schemas for serialization/deserialization:
XML Class Generator for C# using XSD for deserialization
Simple example
After installing Desktop development with C++ as part of the VS Installer, it installs C++ CMake tools for Windows. Let's run this cmake.exe file!
VS Developer Command Prompt
C:\Directory>cmake --version
cmake version 3.21.21080301-MSVC_2
Windows Command Prompt
C:\Directory>cmake --version
'cmake' is not recognized as an internal or external command,
operable program or batch file.
Why example behaves as it does
The VS Developer Command Prompt knew the command cmake, yet the Windows command prompt didn't.
Its almost as if it is and isnt a path variable - Schrodingers cat, errr path!
So where is cmake.exe that the VS developer command prompt says it knows about?
VS Developer Command Prompt
C:\Directory>where cmake
C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe
Okay so that means C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\ must be a PATH variable.
Lets double check:
C:\Directory>set PATH
Path=C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;
It is, great. Now why didnt the windows command prompt find it?
Windows Command Prompt
C:\Directory>set PATH
Hmmm, I'm looking at the list and its not there.
Now Simon Steven's and MikeD's answer can be put in context:
It basically just sets several of the Visual Studio binary locations into the PATH environment variable for that command window instance. This means you can use all the various commands and tools without having to include the full paths.

Resources