As titled, using Powershell after executing
PS C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build> .\vcvarsall.bat amd64
then programs like cl, nmake or msbuild should be available on the path, but they are not
PS C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build> cl
cl : The term 'cl' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
cl
~~
CategoryInfo : ObjectNotFound: (cl:String) [], CommandNotFoundException
FullyQualifiedErrorId : CommandNotFoundException
Specs:
VS 2019 Community Edition with the "Desktop development with C++" workload:
MSVC v142 - VS 2019 C++ x64/x86 build tools (v14.28)
Windows 10 SDK (10.0.18362.0)
Just-In-Time debugger
C++ profiling tools
C++ CMake tools for Windows
C++ ATL for latest v142 build tools (x86 & x64)
Test Adapter for Boost.Test
Test Adapter for Google Test
Live Share
C++ AddressSanitizer (Experimental)
Win10 Pro N x64, 20H2, 19042.746
What am I missing?
Powershell executes the batch file in a child cmd process. The VS environment is set in that cmd process, then gets discarded when the process ends and control returns to Powershell.
The straightforward solution is to reverse the sequence, and set the VS environment before starting the Powershell session so that PS inherits it. Assuming a usual VS installation with the correct VS160COMNTOOLS environment variable set, this can be done by running the following at either a command prompt, via Start / Run, or from PS itself.
cmd /c ""%VS160COMNTOOLS%\..\..\VC\Auxiliary\Build\vcVarsAll.bat" amd64 && start powershell"
See also In a CMD batch file, can I determine if it was run from powershell? and How can I use PowerShell with the Visual Studio Command Prompt? for more discussion and possible alternatives - both for returning environment variables from batch files to PS in general, and for the VS environment in particular.
Related
I previously had Visual Studio 2015 (14.0) Build tools installed, and I could build a simple C++ program, without any IDE, with:
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
cl helloworld1.cpp
Now that I installed Visual Studio 2019 Build Tools, calling vcvarsall.bat gives this message:
Windows cannot find 'powershell.exe'
but after closing the dialog, it still continues (!). But then it fails with:
cl : Command line error D8027 : cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.26.28801\bin\HostX64\x64\c1xx.dll'
I don't see why powershell would be mandatory to just set a few environments variables and set up everything to use cl.exe.
Question: what's the proper way to call cl.exe with VS Build Tools 2019?
Shouldn't we call vcvarsall.bat first, like with previous versions?
(important: I'm looking for a 100% terminal mode, no IDE)
The official way would be to to add %SystemRoot%\System32\WindowsPowerShell\v1.0 to your PATH either permanently or just before calling vcvarsall.bat.
An alternative is to do a set VSCMD_SKIP_SENDTELEMETRY=1 before calling vcvarsall.bat. This works because vcvarsall internally calls vsdevcmd, which in turn uses powershell to configure "send telemetry if user's VS is opted-in". However, the telemetry step is bypassed when VSCMD_SKIP_SENDTELEMETRY is defined (though this appears to be undocumented, and thus subject to change in future versions), then powershell is no longer used or required.
I have a Jenkins slave with Visual Studio 2012 and want to build for x64. What I need is the prompt environment I get when I run the tools prompt link in the Windows Start Menu. People suggest to do it like this (in a Jenkins Windows Batch prompt):
call "%VS110COMNTOOLS%vsvars32.bat" x86_amd64
But this is not enough. There are small differences in the PATH, LIB and LIBPATH environment variables: the paths in there point to the x32 paths only, e.g. to
...;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN;...
instead of
...;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\x86_amd64;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN;...
In fact I am trying to build with the Ninja generator from CMake where the build configuration is determined by the prompt environment.
You need to call vcvarsall.bat x86_amd64 which is located in the VC-subdirectory (and eventually remove parentheses from the PATH):
set path=%path:"=%
call "%VS110COMNTOOLS%..\..\VC\vcvarsall.bat" x86_amd64
If you want to run this in a Pipeline script:
bat """set path=%path:\"=%
call "%vs110comntools%..\\..\\VC\\vcvarsall.bat" x86_amd64
..."""
Recently installed (and re-installed) VS 2012 Ultimate with Blend
The VS Command Prompt doesn't seem to have a reference (are they called environment pathways) to the folder "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\". This means the following lines won't run from the command prompt (either as normal or as administrator)
msbuild buildapp.csproj /t:HelloWorld
Installutil WindowsService1.exe
To use msbuild or Installutil I need to specify the full pathways for the above to run.
Is the above a by design change that MS have made to VS?
In my VS 2012 environment I can find the path you say is missing. I opened the "Developer Command Prompt for VS2012" and did PATH to verify and also ran InstallUtil.exe successfully.
Make sure you open the correct prompt, mine was started using %comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VsDevCmd.bat"
Here's Microsoft's explanation (err..justification :)) of the convoluted path structure :
For 32 bit builds :
Setting the Path and Environment Variables for Command-Line Builds
.. and 64 bit builds :
How to: Enable a 64-Bit Visual C++ Toolset on the Command Line
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;
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.