cmake failed to get the value of VCTargetsPath with VS2019 16.7

Hey guys,
I’m using the latest CMake Version fpr Windows 10 64 Bit (at the moment this is 3.18.2) and the latest VS2019 version (16.7.3)
Now when i run the Cmake generator with the following cmd

cmake -G Visual Studio 16 
/c/git/projpath
 -C/c/git/projpath/build.cmake 
 -DTARGET_SYSTEM:STRING=windows 
 -DBUILD_SYSTEM:STRING=windows 
xxx my other sources
 -DCMAKE_BUILD_TYPE:STRING=debug  -A x64 -DSYSROOT_FOR_BUILD:STRING= -DBUILD_SHARED_LIBS:BOOL=ON

this gives me the error

CMake Error at CMakeLists.txt:40 (project):

Failed to run MSBuild command:

C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/MSBuild/Current/Bin/MSBuild.exe

to get the value of VCTargetsPath:

Microsoft (R)-Build-Engine, Version 16.7.0+b89cb5fde f├╝r .NET Framework
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

now when I install an older version of VS2019 everything works fine. Do you have some hint for me where to look for the problem?

Edit: I allready tried to Run MSBuild via Console
For that I created a simple console application with “hello world”
calling
MSBuild.exe ConsoleApplication1.sln
works fine

Did you miss some quotes in your original cmake command line? Please ensure you show us exactly what you did rather than some approximation of it. If you didn’t use quotes, then that may be the problem. The argument after -G should be "Visual Studio 16" (note the quotes). I also don’t know what xxx my other sources represents - what have you omitted there? You don’t specify source files directly in the cmake command line.

These things may not be related to your actual problem, but eliminate those and it may be easier to look into why the problem is occurring for you (I don’t have any other suggestions beyond the above at the moment).

Hey sorry,
here is my complete unmodified generation cmd

cmake -G "Visual Studio 16" "/c/git/fluegas/t3xx_HIL/t3xx_2017"  \
  -C/c/git/fluegas/t3xx_HIL/build_testclient_3_zellen_2017.cmake \
  -DTARGET_SYSTEM:STRING=windows \
  -DBUILD_SYSTEM:STRING=windows \
  -DT3XX_2017_THIRD_PARTY_LIBS_DIR:STRING=/c/git/fluegas/t3xx_HIL/thirdparty/t3xx_2017/windows/amd64/msvc16/build_testclient_3_zellen_2017 \
  -DT3XX_2017_UNITTESTDATA_DIR:STRING=/c/git/fluegas/t3xx_HIL/test_resources \
  -DSYSTEM:STRING=windows \
  -DT3XX_2017_THIRD_PARTY_LIBS_DIR:STRING=/c/git/fluegas/t3xx_HIL/thirdparty/t3xx_2017/windows/amd64/msvc16/build_testclient_3_zellen_2017 \
  -DT3XX_2017_UNITTESTDATA_DIR:STRING=/c/git/fluegas/t3xx_HIL/test_resources \
  -DT3XX_2017_CMAKE_CONFIGURATION:STRING= \
  -DTESTOLIB_THIRD_PARTY_LIBS_DIR:STRING=/c/git/fluegas/t3xx_HIL/thirdparty/t3xx_2017/windows/amd64/msvc16/build_testclient_3_zellen_2017 \
  -DTESTOLIB_UNITTESTDATA_DIR:STRING=/c/git/fluegas/t3xx_HIL/test_resources \
  -DBUILD_NUMBER:STRING=0 \
  -DGIT_COMMIT:STRING=0 \
  -DGIT_BRANCH:STRING=0 \
  -DCMAKE_INSTALL_PREFIX:STRING=/c/git/fluegas/t3xx_HIL/install/t3xx_2017/windows/amd64/msvc16/build_testclient_3_zellen_2017/dbg/t3xx_2017 \
  -DCMAKE_BUILD_TYPE:STRING=debug \
  -DCMAKE_INSTALL_PREFIX:STRING=/c/git/fluegas/t3xx_HIL/install/t3xx_2017/windows/amd64/msvc16/build_testclient_3_zellen_2017/dbg/t3xx_2017  \
  -A x64 \
  -DSYSROOT_FOR_BUILD:STRING= \
  -DBUILD_SHARED_LIBS:BOOL=ON

Aperantly when I switch back to an old VS2020 (16.5.5) everything works fine.
Does it matter that the -A x64 argument is at the end of the geration cmd in my case?
So something changed within the versions

I reformatted your command to try to better see what’s going on. Please check that it still looks like what you intended.

The only thing odd I can see in there is setting CMAKE_BUILD_TYPE. For Visual Studio, this isn’t used (if the project tries to use it, then that will be a problem because it won’t correspond to the build config used within Visual Studio). There should be no problem with where you’ve placed the -A x64 option on the command line.

Looking more closely at your original error message, it looks like you are using a non-English locale. I don’t know if that’s potentially related to your problem, it would be great if someone familiar with running CMake in a non-English locale could chime in with any thoughts on that.

It would also be worth trying CMake 3.17 or another earlier version to see if this is a regression in the 3.18 release. It might be something that VS changed in recent versions, but if we can eliminate CMake versions from the picture, that may help narrow down the underlying cause.

According to the docs the generator is called "Visual Studio 16 2019". Don’t know if it makes a difference but worth to try.

Hey thx for your replys. I did some version tests.
All tests where run unsing the posted cmd above except with the proper generator "Visual Studio 16 2019"
All VS Versions where taken from https://docs.microsoft.com/en-us/visualstudio/releases/2019/history

  • VS 16.7.3 cmake 3.18.2 =>fail

  • VS 16.7.3 cmake 3.17.4 =>fail

  • VS 16.7.3 cmake 3.16.0 =>fail

  • VS16.5.5 cmake 3.16.0 =>ok

  • Vs 16.6.0 cmake 3.16.0 => ok

  • VS16.6.1 cmake 3.16.0 =>ok

  • VS16.6.2 cmake 3.16.0 =>ok

  • VS16.6.3 cmake 3.16.0 =>ok

  • VS16.6.4 cmake 3.16.0 =>ok

  • VS16.6.5 cmake 3.16.0 =>ok

  • VS 16.7.0 cmake 3.16.0 => fail

  • VS 16.7.0 cmake 3.18.2 =>fail

  • VS 16.6.5 cmake 3.18.2 =>ok

so as you can see. This problem seems to be indepenent of the used cmake version.
The problem arises between VS16.6.5 and VS 16.7.0 So does this help you somehow? I must admit I’m stuck here:O

According to the paths it looks like you are running your generation command from a unixoid terminal (MSYS, Cygwin, WSL) on Windows. Can you try to run your command from a "x64 Native Tools Command Prompt for VS 2019" using Windows paths? The native tools command prompt can be found in the Start menu under the Visual Studio 2019 entry.

@JuliusCaesar Thanks for the tests, that’s quite helpful.

@brad.king This is suggesting that VS may have changed something in a recent version. Do we have any nightly builders running VS 16.7.0 or later? If not, do you have access to such a machine locally? This one may need further investigation as a potential environmental change.

Hey Volker,
I Tried using the VS Command Line.
However this fails due to other reasons. We are using python within our build scripts. Since windows 10 provides it’s own python installation this does not work properly with our whole build routine.
Therefore we are using latest git bash (currently 2.28.0) with latest python (3.8.5) to run the cmake cmd

However since the problem occurs during the cmake -G cmd I’m not sure weather python or gitbash are used for “cmake -G …”

@craig.scott or @brad.king So to reproduce use latest git bash on Windows 10 . Does this help to reproduce the issue?

Do we have any nightly builders running VS 16.7.0 or later?

Yes, and gitlab CI currently runs one of those. It all works fine on multiple machines using both the Community and Professional versions of VS 16.7.

Try running cmake using the form env TEMP= TMP= cmake ...

strange… Are you calling the generation cmd via bash as well?

Try running cmake using the form env TEMP= TMP= cmake ...

do you mean to place this at the top of my build script?

I mean that when cmake -G "Visual Studio 16 2019" ... runs, the environment variables TMP and TEMP should not be set. Update your script to achieve that however you want.

I regularly run the VS generator from a bash prompt, and I did notice recently that with VS 16.7, some tests in our test suite fail if those environment variables are set when MSBuild runs.

Hey,
this thx for your quick support.
I placed the TMP and TEMP before the cmake -G inside our build.sh script

TEMP= TMP= cmake -G "Visual Studio 16 2019 ..."
however this gives me the

Failed to run MSBuild command:

C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/MSBuild/Current/Bin/MSBuild.exe

to get the value of VCTargetsPath:

I noticed that with theese changes mentioned above VS_PATH is empty.
Without these extra TMP,TEMP (and an old VS Version)
VS_PATH = c:/Program Files (x86)/Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\

Did i make something wrong?

While compiling Binaryen I got a similar issue but with better log:

> emsdk install binaryen-master-64bit
Installing tool 'binaryen-master-64bit'..
Repository 'https://github.com/WebAssembly/binaryen.git' already cloned to directory 'C:/Users/Kagami/Documents/GitHub/emsdk/binaryen/master', skipping.
Fetching latest changes to the branch 'main' for 'C:/Users/Kagami/Documents/GitHub/emsdk/binaryen/master'...
Already up to date.
Successfully updated and checked out branch 'main' on repository 'C:/Users/Kagami/Documents/GitHub/emsdk/binaryen/master'
Current repository version: "Sat, 23 Jan 2021 04:27:20 +0900 27a5a7101d20ce5fc51648e775587ab3d640114e"
Running CMake: ['cmake', '-G', 'Visual Studio 16', '-DCMAKE_BUILD_TYPE=Release', '-DPYTHON_EXECUTABLE=C:\\Users\\Kagami\\Documents\\GitHub\\emsdk\\python\\3.7.4-pywin32_64bit\\python.exe', '-A', 'x64', 'C:/Users/Kagami/Documents/GitHub/emsdk/binaryen/master']
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19042.
CMake Error at CMakeLists.txt:2 (project):
  Failed to run MSBuild command:

    C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Framework
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 24/01/2021 1:05:00 PM.
    Project "C:\Users\Kagami\Documents\GitHub\emsdk\binaryen\master_vs2019_64bit_binaryen\CMakeFiles\3.17.1\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\Users\Kagami\Documents\GitHub\emsdk\binaryen\master_vs2019_64bit_binaryen\CMakeFiles\3.17.1\VCTargetsPath.vcxproj(15,2): error MSB4019: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Default.props" was not found. Confirm that the expression in the Import declaration "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Default.props" is correct, and that the file exists on disk.
    Done Building Project "C:\Users\Kagami\Documents\GitHub\emsdk\binaryen\master_vs2019_64bit_binaryen\CMakeFiles\3.17.1\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\Users\Kagami\Documents\GitHub\emsdk\binaryen\master_vs2019_64bit_binaryen\CMakeFiles\3.17.1\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\Users\Kagami\Documents\GitHub\emsdk\binaryen\master_vs2019_64bit_binaryen\CMakeFiles\3.17.1\VCTargetsPath.vcxproj(15,2): error MSB4019: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Default.props" was not found. Confirm that the expression in the Import declaration "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Default.props" is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)

    Time Elapsed 00:00:00.18


  Exit code: 1



-- Configuring incomplete, errors occurred!
See also "C:/Users/Kagami/Documents/GitHub/emsdk/binaryen/master_vs2019_64bit_binaryen/CMakeFiles/CMakeOutput.log".
CMake invocation failed due to exception!
Working directory: C:/Users/Kagami/Documents/GitHub/emsdk/binaryen/master_vs2019_64bit_binaryen
Command '['cmake', '-G', 'Visual Studio 16', '-DCMAKE_BUILD_TYPE=Release', '-DPYTHON_EXECUTABLE=C:\\Users\\Kagami\\Documents\\GitHub\\emsdk\\python\\3.7.4-pywin32_64bit\\python.exe', '-A', 'x64', 'C:/Users/Kagami/Documents/GitHub/emsdk/binaryen/master']' returned non-zero exit status 1.
Installation failed!

Microsoft Visual Studio\2019\Community\Common7\IDE\VC\VCTargets doesn’t exist anymore in the latest VS2019.

@krosylight take a look at CMakeFiles\3.17.1\VCTargetsPath.vcxproj in an editor. The failing line is probably just <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props"/>. If the imported file is missing, that means Visual Studio’s own VCTargetsPath is incorrect. This likely indicates a problem with its installation.

1 Like