In Visual Studio Code 2017: msbuild : The term 'msbuild' is not recognized as the name of a cmdlet - c++

msbuild : The term 'msbuild' is not recognized as the name of a cmdlet,
function, script file, or operable program.
As far as my googling goes, Visual Code should come with MSbuild. I have installed the C/C++ and msbuild Tools extensions to no avail. What can I do?
Edit: I am using Visual Studio Code 1.19.2

Likely it's a path issue. If you have VS2017 installed, it's probably in the directory C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
Try adding that to your path, then restart VS Code and try again.

I suggest you rethink you command-line approach.
Short plan
Install Visual Studio Build Tools 2017
Find proper MSBuild
Use it
Details
Using Build Tools will give you independence from Visual Studio installation.
Download Build Tools for Visual Studio 2017 from Visual Studio Downloads page (direct link)
Command-line arguments documented here: Use command-line parameters to install Visual Studio 2017
All workloads and components are listed here: Visual Studio Build Tools 2017 component directory
You can use PowerShell module VSSetup. Download it or install from here: Github: Microsoft/Visual Studio Setup PowerShell Module
Run MSBuild with build target (you can add additional required parameters)
# 1. Find MS Build
Import-Module $PSScriptRoot\VSSetup\VSSetup.psd1
$msBuildPath = (Get-VSSetupInstance | Select-VSSetupInstance -Version 15.0 -Product Microsoft.VisualStudio.Product.BuildTools).InstallationPath
if ([System.IntPtr]::Size -eq 8)
{
$global:msbuildPath = Join-Path $msBuildPath 'MSBuild\15.0\Bin\amd64'
}
else
{
$global:msbuildPath = Join-Path $msBuildPath 'MSBuild\15.0\Bin'
}
Write-Output "Using MSBuild from $global:msbuildPath"
Write-Output "MSBuild /version"
$msbuild = Join-Path $global:msbuildPath msbuild
& $msbuild /version
# 2. Build
& $msbuild "$sln_file" /t:Build /v:q /nologo

I don't believe that this is a good solution, but it's what I hacked together since the other suggestions didn't work. I installed Visual Studio Installer and installed MSBuild through that. I am having other issues now but at least msbuild is running.

I faced the same issue, what worked with me was to use dotnet instead of msbuild :
dotnet build

Related

Change Platform Toolset when compiling from CMD

I would like to compile a C++ program via Visual Studio command line tools. I would like to target the executable for 32 bit Windows XP. Tried compiling it the usual way, using x86 Native Tools Command Prompt for VS 2019, but it doesn't work on Windows XP, though runs fine on my Windows 10 machine.
Steps I take:
Open x86 Native Tools Command Prompt for VS 2019.
cd to the project directory. There I'll have 2 folders sources and headers, which shall contain .cpp and .h files respectively.
Execute command cl sources\*.cpp /EHsc /D_WIN32_WINNT=0x050103 /I headers /I <path to boost> /link /libpath <path to boost>\boost_1_77_0\bin\x86\lib\libboost_program_options-vc142-mt-s-x32-1_77.lib /out:exec_xp.exe (the project uses the boost library).
Tried this, but it doesn't work. /D \"_USING_V110_SDK71_\" seems to do nothing, and the /SUBSYSTEM:WINDOWS,5.01 piece isn't recognized by the compiler.
I have learnt from this Microsoft page that we should install deprecated Toolset to compile for WinXP. I went ahead to Visual Studio Installer and installed the C++ Windows XP Support for VS 2017 (v141) tools [Deprecated], as said in the tutorial.
But what now? How can I use this Toolset? I can't find it anywhere on my computer, let alone use it! Visual Studio Installer says it's located under C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools, but it's too vague.
UPD:
Tried with msbuild /p:PlatformToolset=v141_xp, getting this error:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(439,
5): error MSB8020: The build tools for v141_xp (Platform Toolset = 'v141_xp') cannot be found. To build using the v141_
xp build tools, please install v141_xp build tools. Alternatively, you may upgrade to the current Visual Studio tools
by selecting the Project menu or right-click the solution, and then selecting "Retarget solution"
Which suggests, the compiler doesn't see the v141_xp toolset. I wonder why? It's installed for sure, I did it via the Visual Studio Installer.
I suggest you could try to set the PlatformToolset property:
msbuild myProject.vcxproj /p:PlatformToolset=…
For more details, I suggest you could refer to the Doc:MSBuild command-line reference

Unable to run msbuild for C++ from the command line VS2017

I have a project that has only ever lived in Visual Studio 2017. It's a C++ dll, and up until this point I've had no problem building it from within the Visual Studio GUI. However now I'm trying to set up automation that will build the project on the command line and upload the output files to a desired location. Here's what I've tried so far (in a brand new Command Prompt):
cd C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>
vcvarsall amd64
cd C:\Users\me\development\MyProject
msbuild MyProject.slnl (or msbuild MyProject\MyProject.vcxproj)
And this gives me the error output
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140\Microsoft.Cpp.Platform.targets(57,5):
error MSB8020: The build tools for v141 (Platform Toolset = 'v141') cannot be found. To build
using the v141 build tools, please install v141 build tools. Alternatively, you
may upgrade to the current Visual Studio tools by selecting the Project menu or right-cli
ck the solution, and then selecting "Retarget solution".
[C:\Users\dev\development\MetaReme\MetaReme\MetaReme.vcxproj]
Let me reiterate that I've been successfully building within Visual Studio 2017 targeting the v141 toolset, it's just on the command line I'm having trouble. Within my Visual Studio Installer application I have the VC++ 2017 v141 toolset checked. I've looked on the filesystem and within C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\ there is no v141 folder.
Thanks!
Thanks guys! I was following https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line which says "By default, these tools are installed in drive:\Program Files (x86)\Microsoft Visual Studio version\VC\bin.". Obviously these docs are outdated... I was able to get it to work with the following commands
cd "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build"
vcvars64
cd "C:\Users\me\development\MyProject"
msbuild MyProject.sln
It says in the first part of the paragraph in the mentioned article:
In Visual Studio 2017, these are located in the VC\Auxiliary\Build subdirectory of the Visual Studio installation directory. In Visual Studio 2015, these are located in the VC, VC\bin, or VC\bin\architectures subdirectories of the installation directory, where architectures is one of the native or cross compiler options.
As you are using Visual Studio 2017, they should be in VC\Auxiliary\Build, like you found out.
Another way to find the correct .bat files would be through the command prompt shortcuts mentioned in the same article. First locate them by expanding start->Visual Studio Year, right click and find their location. Then check the location they are pointing to.

MSbuild Error: The builds tools for v140 (Platform Toolset = 'v140') cannot be found

I have a solution which is consists of a large number of projects (C++ and C#). I upgraded the solution to VS2015, so the toolset version for most of them are now set to V140, but a small number of projects need to remain in V110 (third party libraries, etc). When I build the solution in Visual Studio 2015, it builds just fine, but when TeamFoundationServer tries to build it, it fails with the following error:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.targets (44): The builds tools for v140 (Platform Toolset = 'v140') cannot be found. To build using the v140 build tools, either click the Project menu or right-click the solution, and then select "Update VC++ Projects...". Install v140 to build using the v140 build tools.
I tried to specify the VisualStudioVersion or the path to the right MSBuild version as build arguments, but it didn't work as the rest of the projects (the ones in V110) will be in trouble.
Any help would be very appreciated.
I had the same issue. Steps given in this Solution helped me solve my issue. Repeating the steps here for future reference.
If you're attempting to build a Win32 "Desktop" application, the easiest way to get the v140 Platform Toolset is via the Visual Studio Installer (please see the image, below, for an illustration of steps '3.' and '4.'):
Launch the "Visual Studio Installer" from your start menu.
Select "Modify" for the instance of Visual Studio 2017 you have
installed.
Under the "Summary" pane of the workload selector, click the
"Desktop development with C++" expander (if it is collapsed)
Check the "VC++ 2015.3 v140 toolset (x86,x64)" optional feature.
The builds tools for v140 that's the platform toolset for VS2015.
If you are using TFS2015, you must make sure the build environment on your build machine be the same as your local developer machine. You should install VS2015 on your build machine.
If you are using TFS2013 or TFS2012, most probably MSBuild 12.0 is called.You need to set the build templates to point to MS Build version 14.0. For the details, check: TFS 2013 building .NET 4.6 / C# 6.0
Jacob's answer worked for me but C++ build tools were under VS Build Tools 2017 while I had VS 2019 Installer on Windows 10 as at July, 2019.
You're trying to build using a different version of the build toolset that is either not installed on your system or that the project can't use. To change it to something that you have installed on your system, right click on the project in your Solution Explorer.
Go to Properties. Configuration Properties>General>Platform Toolset>(Change this to a toolset that is installed on your system).
Make sure you do this for the Debug and Release builds
For the folks who are trying to do the same with Visual Studio Build Tools 2022, you may find this under Optional when choosing Desktop development with C++ Workload. Also, I had to update below variables in Environment variables to point to the new location.
Path: replace previous path for BuildTools with C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin
VCTargetsPath: C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Microsoft\VC\v170
VS140COMNTOOLS: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\ PS: I didn't have to change the value. But this setting was needed for me to work.
If you are using Visual Studio 2022 Build Tools, then the following PowerShell script will fix it:
$VS_BTOOLS_EXE="vs_buildtools.exe"
$VS_BTOOLS_URI="https://aka.ms/vs/17/release/vs_buildtools.exe"
Invoke-WebRequest -Uri $VS_BTOOLS_URI -OutFile $VS_BTOOLS_EXE
Start-Process -FilePath ./vs_BuildTools.exe -ArgumentList `
"--add", "Microsoft.VisualStudio.Component.VC.140", `
"--quiet", "--norestart", "--force", "--wait" -Wait -PassThru
Useful when silent installation is needed as well.
Jacob's answer worked for me, but I had to click on the "Individual components" tab at the top for my Step 3.
image
This solution worked perfectly for me: https://social.msdn.microsoft.com/Forums/vstudio/en-US/e0b9c601-2ece-4dcc-bac3-23ed7dd6801a/the-builds-tools-for-v120-platform-toolset-v120-cannot-be-found?forum=vclanguage

CMake does not find Visual C++ compiler

After installing Visual Studio 2015 and running CMake on a previous project, CMake errors stating that it could not find the C compiler.
The C compiler identification is unknown
The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:4 (PROJECT):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:4 (PROJECT):
No CMAKE_CXX_COMPILER could be found.
I went searching for cl.exe in the Visual Studio folder,C:\Program Files\Microsoft Visual Studio 14.0, and could not find it.
How do I set up CMake to work on Windows with Visual Studio 2015?
I have found the solution. While the Visual Studio IDE installed successfully it did not install any build tools and therefore did not install the C++ compiler.
By attempting to manually create a C++ project in the Visual Studio 2015 GUI I was able to prompt it to download the C++ packages. CMake was then able to find the compiler without any difficulty.
Here is the solution that worked for me:
Open Visual Studio command prompt tool (as an administrator). On windows 10 it might be called 'Developer command prompt'.
Navigate to where you have the CMake executable
Run Cmake.exe
Proceed as usual to select build and source folder
Select the appropriate Visual Studio compiler and hit the configure button
Hopefully it should run without problems.
I looked in CMakeError.log file and found an error about cannot run 'rc.exe'
I searched and found this answer to copy RC.Exe and RcDll.Dll from the Microsoft SDKs bin to the VC bin, and then CMake worked.
Edit: The top answer to another question suggests that it's a PATH issue, so it could be enough to ensure the Microsoft SDK bin is in your PATH.
Those stumbling with this on Visual Studio 2017: there is a feature related to CMake that needs to be selected and installed together with the relevant compiler toolsets. See the screenshot below.
Make sure you are using the correct version of Visual Studio in the generator. I had incorrectly selected Visual Studio 15 when Visual Studio 14 installed.
If none of the above solutions worked, then 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.
For me, I checked the CMakeError.log file and found:
[...] error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution".
This is despite using Visual Studio 2017 on Windows 7. So it appears that CMake is trying to build its detection project with the Windows 8.1 SDK.
I used the Visual Studio installer to add that component and now CMake is happy as a clam.
Menu → Visual Studio 2015 → MSBuild Command Prompt for Visual Studio 2015. Then CMake can find cl.exe.
set PATH="c:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64\";%PATH%
Change the upper path to where your Windows SDK is installed.
CMake can find rc.exe.
cd to the path of CMakeLists.txt and do:
md .build
cd .build
cmake .. -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
cmake --build .
The param after -G should be fetched by CMake. Use --help; you may or may not have the generator.
I ran into the same issue and fixed it by relaunching the Visual Studio Install and checking the following option:
Windows and Web Development / Universal Windows App Development Tools / Windows 10 SDK
It contains the standard C++ headers used in most applications and therefore it is often necessary to install it as well.
I had this issue under Windows 10 when using Visual Studio 2015 Professional, while Visual Studio 2015 Express worked! Under Windows 7, both Visual Studio versions used to work.
New projects created from the Visual Studio 2015 Professional IDE successfully compile, but CMake would fail to find the compiler reporting:
The C compiler identification is unknown
The CXX compiler identification is unknown
I upgraded CMake from 3.4.1 to 3.11.4, and now the problem is gone.
If you are on Visual Studio 2017 you need at least CMake 3.8!
I had a similar problem with the Visual Studio 2017 project generated through CMake. Some of the packages were missing while installing Visual Studio in Desktop development with C++. See snapshot:
Visual Studio 2017 Packages:
Also, upgrade CMake to the latest version.
Checking CMakeErrors.log in CMakeFiles returned:
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140_xp\Toolset.targets(36,5): warning MSB8003: Could not find WindowsSdkDir_71A variable from the
registry. TargetFrameworkVersion or PlatformToolset may be set to an
invalid version number.
The error means that the build tools for XP (v140_xp) are not installed. To fix it I installed the proper feature in Visual Studio 2019 installer under Individual Components tab:
I was running old cmake version (i.e. 3.8) and I'm using visual studio 16 - 2019. After updating my cmake version, it did detect the compiler.
In my case there was an environment variable set which was the reason for this error.
The problem was solved after deleting cxx_flags from the environment variables.
I got this problem with CMake 3.12.1, after an update of Visual Studio 2017. I simply re-ran CMake and it worked.
In my case I could see in the CMakeError.log that CMake could not find the Windows SDK (MSB8003: Could not find WindowsSDKDir variable from the registry).
The version can be specified on the commandline on the first CMake run using:
-DCMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION=
I got further after setting that, but I hit more issues later (so I assume my environment is messed up somehow), but maybe it will help someone with this issue.
A couple of tips:
Try to set the path manually by checking 'advanced' and modifying CMAKE_LINKER and CMAKE_MAKE_PROGRAM
Delete the cache - in the CMake with GUI go to:
File → Delete Cache.
My problem was a combination of previously stated: I have set the compiler version to 15 instead of 14 and when corrected, I had to delete the cache.
I also started the Visual Studio command prompt as an administrator and from there I ran the cmake-gui.exe
Then everything worked as it was supposed to.
In my case the issue was that the parent project, which is including googletest via
add_subdirectory(gtest_dir)
was defined as
PROJECT( projname CXX )
Somehow, CMake does not recognize
PROJECT(sub_project_name CXX C)
since the C compiler is not set in the parent.
I solved the issue by using
PROJECT( projname CXX C)
in my main CMakeLists.txt file.
This might be another solution for those with the latest Windows 10 creator version:
Stack Overflow post Fatal error LNK1104: cannot open file 'gdi32.lib'
None of the previous solutions worked for me. However I noticed that although I installed Visual Studio version 15 (not to be confused with Visual Studio 2015) the directory created on my computer was for Visual Studio 14.
When I specified Visual Studio 14 when I pressed the configuration button it worked.
i found this sollution at stackoverflow and i work for me although not working other sollutions
if you have a windows 10 OS, doing the following steps will fix the problem:
1) go to C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin
2) then copy RC.exe and RcDll from this file
3) go to C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin and paste the two files you have copied into it.
thats all i hope it is helpful...
Look in the Cmakelists.txt if you find ARM you need to install C++ for ARM and as well vcvarsall.bat use for ARM bin folder.
It's these packages:
C++ Universal Windows Platform for ARM64 "Not Required"
Visual C++ Compilers and libraries for ARM "Not Required"
Visual C++ Compilers and libraries for ARM64 "Very Likely Required"
Required for finding Threads on ARM
enable_language(C)
enable_language(CXX)
Then the problems might disappear:
No CMAKE_C_COMPILER could be found.
No CMAKE_CXX_COMPILER could be found.
If above does not resolve your problem?
Optionally you can remove the options C and CXX in cmakelists.txt by setting # infront of where the enable_language(C) is. And avoid Android ARM processor compilation.
Resolved by adding the missing component
Modify->continue add as follow
I had a related problem: the Visual C++ generators were not even on the list when running cmake --help.
I ran where cmake in console and found that cygwin also provides its own cmake.exe file, which was being used. Changing the order of directories in PATH fixed the problem.
I had this issue with CMake GUI and the VS 21019 Community Edition. I think I may have installed CMake before Visual Studio - certainly after I updated CMake 3.15.2 to 3.15.3 the problem went away.
Check name folder too long or not.
This question is old, but none of the solutions here were working for me. I'm using Visual Studio 2019, and in my case, C++ compilation was working but just broke one day.
However, I noticed that there was an update ready to be installed in the Visual Studio Installer.
After installing that update, rebooting my computer, and relaunching Visual Studio, all of the C++ CMake problems disappeared. I'm not quite sure why this fixed it, and I can only speculate, but I can only assume that one of two things occurred. Either installing that update fixed a broken installation, or the update was quietly downloaded and prepared in the background, breaking things in the process.
I met the same issue in VSCode Cmake extension, i solve it by check following two options:
In the end, click [Scan for kits]
cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\gcc.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\g++.exe" -Hc:/code -Bc:/code/build -G "MinGW Makefiles"

Building Visual Studio 2008 solution from 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