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;
Related
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
Because the VS 2015 Installer was crashing all the time, I had to use the silent installation. Now I don't have the "Visual Studio Command Prompt" Shortcut in Start menu. Can I find it somewhere else?
I had to create the shortcuts manually as well, but they all follow the same pattern so no biggie:
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" x86
Don't forget to change the execution path to: "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\"
Replace the last bit (x86) with the tool you want to use:
x86
amd64
arm
x86_arm
x86_amd64
amd64_x86
amd64_arm
Visual studio command prompt is nothing but the regular command prompt where few environment variables are set by default. This variables are set in the batch script : C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat . So basically to get a visual studio command prompt for a particular version, just open regular command prompt and run this batch script : C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat (Change the visual studio version based on your installed version). Voila you have got the visual studio command prompt. You can write a script to run the batch file and open cmd.exe and have a shortcut for the same.
Where do I run this syntax? There's no command line on Visual Studio. I know this is a simple question but so far I couldn't find the answer.
Usually, after installation of Visual Studio, you have a submenu entry inside the Microsoft Visual Studio program group called Visual Studio Tools. In this submenu you could find a couple of Command Prompt for ... menu that launch a command window with specific path set to the Tools installed with Visual Studio, including the LIB tool
For example, this is the command executed by one of mine menu entries
%comspec% /k ""c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86_amd64
I added the bin directory of the VS2010 (not SP1) C++ compiler to my PATH variable on Windows XP. When i try to run it, it tells me that a DLL was not found.
I added this line to my PATH:
C:\Program Files\Microsoft Visual Studio 10.0\VC\bin;
Update: it still fails when I cd to the bin directory above, and then run the compiler
Can you help me out?
Run the VS command prompt shortcut or the batch file it points to, such as:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86
to set up an appropriate environment including the path.
By the way, mspdb100.dll lives in C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE. But run the shortcut/batch file anyway - it does more than set up the correct path.
add Microsoft Visual Studio 10.0\Common7\IDE to your Path variable, than close cmd prompt and open it. now it will work.
Running the VS command prompt takes care of setting up the environment. Also, ensure that you are running the command prompt as an admin.
Installing Visual Studio 2010 SP1 C++ Compiler Setup fixed this issue for me. Visual Studio 2010 SP1 C++ Compiler install
I faced the same issue when I tried to run a 32 bit exe I built, on a 64 bit machine.
"mspdb100.dll couldn't be found by cl.exe "
Visual Studio 2010(the version I currently use) builds a 32 bit exe by Default.To create a 64 bit executable, just change the setting from Win32 to x64 in the dropdown box at the top of VS and build.This will build for you a 64 bit executable and solve your problem.
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.