Login/Register
Why does MSBuild look in C:\ for Microsoft.Cpp.Default.props instead of c:\Program Files (x86)\MSBuild? ( error MSB4019)
Asked Answered
Solved msbuild
P

24

137

When I run msbuild to build a vc2010 project I get the following error:

error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. 
Confirm that the path in the <Import> declaration is correct, and that the file exists 
on disk.
  • msbuild located c:\Program File (x86)\MSBuild
  • HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolVersions\V4.0 VCTargetsPath set to $(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\
  • when running msbuild /verbosity:diag as good system shows MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath set as Environment at start of build
  • setting MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath set as environment variables in shell doesn't cause them to show as Environment at start of build

Fixes Attempted

  • Uninstalled .net 4.5, repaired .net 4.0
  • Set MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath in system variables.

It appears that MSBuildExtensionsPath32 isn't being set properly and setting MSBuildExtensionsPath doesn't help

SET MSBuildExtensionsPath="C:\Program Files\MSBuild"

Please let me know if you have any ideas what's blocking the proper setting of this variable.

Playoff answered 18/4, 2013 at 20:10 Comment(1)
Great! Another question about an error resulting from a corrupted Visual Studio installation with hundreds of workarounds that each only work in a select few scenarios... – Nameplate
P
52

For those who didn't follow the MS proscribed order (see Xv's answer) you can still fix the problem.

MSBuild uses the VCTargetsPath to locate default cpp properties but cannot because the registry lacks this String Value.

Check for the String Value

  • Launch regedit
  • Navigator to HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Inspect VCTargetsPath key. The value should = "$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

To fix

  • Launch regedit Navigator to HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Add String Value VCTargetsPath
  • Set Value to "$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

Note: HKLM stands for HKEY_LOCAL_MACHINE.

Playoff answered 25/4, 2013 at 18:27 Comment(10)
The registry entry was already there for me. I had to define an environment variable with that name set to the value in the registry to get past that one: set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0 – Heaney
for me it's worked only with this set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v120 – Sommers
Building eventstore, this answer helped but not completely. Turns out the project builds children projects that use ToolsVersion 12.0. I solved it by setting another string value VCTargetsPath in HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0 – Scorpaenoid
@cmm-user HKLM stands for HKEY_LOCAL_MACHINE you should definitely have it in regedit – Ecology
VCTargetsPath is not a key, but a String Value! – Exit
Does your answer imply that VS has to be installed? Can we do without bringing huge IDE into the system? By only installing build tools – Sidnee
@Sidnee I had the ides installed. Can't say if it's possible without. This solved my problem but it's probably not the solution to all such problems unfortunately. – Playoff
For me it was now set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140 – Rouse
It worked for me with setting BOTH the key string in the registry and the environment variable like @Sommers said. Also, be sure to locate the .props files in the explorer to set the full correct path. For me, it was C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140 – Hotbox
This answer is incorrect. I already had these exact registry values, and I'm still getting these errors. – Rhetic
S
80

I got this problem when publishing a cocos2d-x application using their command line tool, which calls MSBuild. I'm using Win 7 64-bit, VS2013 express, cocos2d-x version 3.3, .NET Framework 4.5 installed.

I fixed the problem by setting the following before running the cocos.py publish command:

SET VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120
Selfregard answered 24/12, 2014 at 3:28 Comment(4)
This helped me to install the oracledb node package. I followed instructions on community.oracle.com/docs/DOC-931127 and even so I got error MSB4019, which I fixed with this answer. – Etra
PowerShell version: [Environment]::SetEnvironmentVariable("VCTargetsPath", "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140", "Machine") – Swetlana
Helped with path ended with 'v4.0' – Alligator
there's also the 'setx' command with /m flag for windows server – Lioness
P
52

For those who didn't follow the MS proscribed order (see Xv's answer) you can still fix the problem.

MSBuild uses the VCTargetsPath to locate default cpp properties but cannot because the registry lacks this String Value.

Check for the String Value

  • Launch regedit
  • Navigator to HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Inspect VCTargetsPath key. The value should = "$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

To fix

  • Launch regedit Navigator to HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Add String Value VCTargetsPath
  • Set Value to "$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

Note: HKLM stands for HKEY_LOCAL_MACHINE.

Playoff answered 25/4, 2013 at 18:27 Comment(10)
The registry entry was already there for me. I had to define an environment variable with that name set to the value in the registry to get past that one: set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0 – Heaney
for me it's worked only with this set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v120 – Sommers
Building eventstore, this answer helped but not completely. Turns out the project builds children projects that use ToolsVersion 12.0. I solved it by setting another string value VCTargetsPath in HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0 – Scorpaenoid
@cmm-user HKLM stands for HKEY_LOCAL_MACHINE you should definitely have it in regedit – Ecology
VCTargetsPath is not a key, but a String Value! – Exit
Does your answer imply that VS has to be installed? Can we do without bringing huge IDE into the system? By only installing build tools – Sidnee
@Sidnee I had the ides installed. Can't say if it's possible without. This solved my problem but it's probably not the solution to all such problems unfortunately. – Playoff
For me it was now set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140 – Rouse
It worked for me with setting BOTH the key string in the registry and the environment variable like @Sommers said. Also, be sure to locate the .props files in the explorer to set the full correct path. For me, it was C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140 – Hotbox
This answer is incorrect. I already had these exact registry values, and I'm still getting these errors. – Rhetic
O
26

I have had the same problem recently and after installing different packages in different order it was just getting very messy. Then I have found this repo - https://github.com/felixrieseberg/windows-build-tools

npm install --global windows-build-tools

It installs Python & VS Build tools that are required to compile most node modules. It worked a treat!

Ophthalmoscopy answered 3/1, 2017 at 23:22 Comment(2)
Good thing but does not work for Azure unfortunately. – Biotin
For those that might be having an issue like me. I needed the --production option. npm install --global --production windows-build-tools As per the node-gyp install instructions: github.com/nodejs/node-gyp – Stets
F
24

For Visual Studio 2017 and 2019 on Windows 10

A lot of the answers here apply to older versions of Visual Studio. What worked for me, if using Visual Studio 2017 Community version, was setting an environment variable called VCTargetsPath and giving it a value of

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets

If using Visual Studio 2019 Community version,

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160

Other answers here set this variable to c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140 but I noticed in my visual studio installation, there was no folder called Microsoft.Cpp in my MSBuild folder. So keep this in mind as well as the fact that the path above is for the Community version of Visual Studio 2017.

Also, make sure that your MSBuild path in your environment variables points to the correct version of MSBuild if you're using Visual Studio 2017 Community version,

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin

If you're using Visual Studio 2019 Community version,

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin
Forebrain answered 19/1, 2019 at 20:9 Comment(5)
In mine, VCTargetPath was C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets – Marou
It could also be Microsoft Visual Studio\2019\BuildTools or similar variations - and I suppose instead of BuildTools and Community you could also have Professional and Enterprise. vswhere.exe -products * -property installationPath will search for all combinations, and return the locations of all installed products. – Conners
'vswhere.exe' is not recognized as an internal or external command, operable program or batch file. – Rhetic
@AndrewKoster vswhere seems to be in C:\ProgramFiles (x86)\Microsoft Visual Studio\Installer\vswhere.exe – Benediction
learn.microsoft.com/en-us/cpp/build/reference/… – Durkee
K
14

Installing Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1 fixed the MSB4019 errors that I was getting building on Windows7 x64.

The readme of that update states that the recommended order is

  1. Visual Studio 2010
  2. Windows SDK 7.1
  3. Visual Studio 2010 SP1
  4. Visual C++ 2010 SP1 Compiler Update for the Windows SDK 7.1
Kimsey answered 25/4, 2013 at 11:22 Comment(1)
Oh ok. I figured out the fix for this. Add in the missing registry key. I'll post it and update my setup docs to follow this order – Playoff
E
6

On 64-bit systems, MSBuild defaults to the following properties (where C: is SystemDrive):

MSBuildExtensionsPath = C:\Program Files (x86)\MSBuild
MSBuildExtensionsPath32 = C:\Program Files (x86)\MSBuild
MSBuildExtensionsPath64 = C:\Program Files\MSBuild

If it doesn't, it means you either have some custom third-party overrides targets installed, or your MSBuild installation is corrupted.

Things to try:

  • Repair .NET installation
  • Apply latest Visual Studio Service Pack
  • Set MSBuildExtensionsPath manually as above (note the x86 part on 64-bit machines)
Eluviation answered 18/4, 2013 at 21:30 Comment(1)
Thanks but Those still aren't set after: 1) repaire .net 4.5, 2) uninstall .net 4.5 and repair 4.0. If I set them manually in the environment it doesn't work either – Playoff
G
6

MSBuild in an independent build tool that is frequently bundled with other tools. It may have been installed on your computer with .NET (older versions), Visual Studio (newer versions), or even Team Foundation Build.

MSBuild needs configuration files, compilers, etc (a ToolSet) that matches the version of Visual Studio or TFS that will use it, as well as the version of .NET against which source code will be compiled.

Depending on how MSBuild was installed, the configuration files may be in one or more of these paths.

  • C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\
  • C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\
  • C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\

As described in other answers, a registry item and/or environmental variable point must to the ToolSet path.

  • The VCTargetsPath key under HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • The VCTargetsPath environmental variable.

Occasionally, an operation like installing a tool will leave the registry and/or environmental variable set incorrectly. The other answers are all variations on fixing them.

The only thing I have to add is the environmental variable didn't work for me when I left off the trailing \

Gradygrae answered 22/1, 2017 at 2:5 Comment(2)
This! We had problems on our build agent with no full VS2017 install. We reinstalled the "Workload" with a given VC tool set - not the individual component, and it did a correct install. We suspect Visual Studio installer did not put the right toolset v141 under VS2017 during our custom component selection install. – Larondalarosa
For me, this helped fix it - a script I was using was "helpfully" finding the wrong msbuild.exe and calling it explicitly. – Ululant
P
5

I had this problem on Visual Studio 2015 edition. When I used cmake to generate a project this error appeared.

error MSB4019: The imported project "D:\Microsoft.Cpp.Default.props" was not found

I fixed it by adding a String

VCTargetsPath

with value

$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140

in the registry path

HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0

Peroration answered 5/7, 2018 at 11:17 Comment(1)
Done this. Restarted the cmd after, but doesn't fix the issue. – Gipsy
N
5

EDIT: This applies to older versions of Visual Studio / MSBuild (specifically MSVC2015?). With more modern versions, MSBuild is included in Visual Studio Build Tools 2019, and compilers are located in different places and detected in different ways.

This is due to a mismatch of installed MSBuild toolsets and registry settings. It can happen if you did one or more of the following:

  • Install multiple Visual Studio versions in the wrong order
  • Uninstall one or more versions of Visual Studio
  • Manually make registry changes or modifications to the Visual Studio installation

The only safe and reliable solution I know of is to reinstall your OS. If your project needs multiple versions of Visual Studio to build, install the oldest version first. Then fix your code so you can use one single tool to build it, or you or your colleagues will be in the same mess again soon.

If this is not an option for you, first read https://mcmap.net/q/161371/-why-does-msbuild-look-in-c-for-microsoft-cpp-default-props-instead-of-c-program-files-x86-msbuild-error-msb4019 for a better understanding of the problem and what the various "solutions" actually do. Then, depending on your Visual Studio version and setup, one of the other answers or variations of them may eventually help.

Some more hints:

Nameplate answered 11/10, 2018 at 15:15 Comment(0)
B
4

The registry entries for MSBuild key worked fine to me. It's important to remember that it must be done for 64-bit or 32-bit branches depending on which version of MSBuild you run. I wouldn't recommend to use environment variables as it may cause problems in different versions of MSBuild.

This registry file fixes that for both cases:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0\10.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0\11.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0\12.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\10.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\11.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\12.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
Buddy answered 17/8, 2018 at 16:23 Comment(0)
I
2

Installing Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1 worked for me. However, I experienced issues with the update because I already had VS 2010 and VS 2010 SP1 installed. As mentioned by Xv above, the readme.htm file contains solutions for the most common installation issues in the "Known Issues" section. I would follow the instructions in the readme.htm and reboot your machine after each troubleshooting attempt because some installs write to your registry.

Ivories answered 1/5, 2014 at 18:28 Comment(0)
M
2

Nothing else worked for me except, setting the path as:

C:\Program Files\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0
Marconigraph answered 28/9, 2018 at 13:9 Comment(1)
which path should i set? – Venter
L
2

In my case, I've added an Environment variable VCTargetPath with path

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\"

('\' at the end is crucial, as the project solution files has a reference to "Microsoft cpp targets" file.

Also, starting from Visual Studio 2017 MSBUILD comes along within Visual Studio - so, the PATH variable needs to be updated with

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin

Updating VCTargetPath and MSBUILD's PATH variables and building fixed the error.

Lunate answered 17/12, 2019 at 11:42 Comment(0)
O
1

Instead of setting a fixed path try this in your post-build command-line first:

SET VCTargetsPath=$(VCTargetsPath)

The variable '$(VCTargetsPath)' seems to be a c++-related visual-studio-macro which is not shown in c#-sdk-projects as a macro but is still available there.

Orren answered 13/2, 2020 at 14:55 Comment(0)
A
0

I came across this error by writing a Build script that would put MSBuild on the %PATH% after recursively digging through the C:\Windows\Microsoft.NET folder for any found MSBuild.exe files. The last found hit was the directory that was put on the path. Since the dir command would hit the Framework64 folder after Framework I was getting one of the 64bit MSBuilds put on my path. I was trying to build a Visual Studio 2010 solution and wound up altering my search string from C:\Windows\Microsoft.NET to C:\Windows\Microsoft.NET\Framework so that I would wind up with a 32bit MSBuild.exe. Now my solution file builds.

Aluminize answered 9/11, 2015 at 23:41 Comment(0)
M
0

I just added VCTargetsPath={c:\...} as an environment variable to my Hudson job.

Mcinerney answered 1/4, 2016 at 10:34 Comment(0)
A
0

For the record, the file Microsoft.Cpp.Default.props can modify the env var VCTargetsPath and make subsequent usages of that var incorrect. I had that problem and solved it by setting VCTargetsPath10 and VCTargetsPath11 to the same value than VCTargetsPath.

This should be adapted according to the VS version you are using.

Arrowworm answered 29/5, 2017 at 15:12 Comment(0)
T
0

I'm seeing this in a VS2017 environment. My build script calls VsDevCmd.bat first, and to solve this problem I set the VCTargetsPath environment variable after VsDevCmd and before calling MSBuild:

set VCTargetsPath=%VCIDEInstallDir%VCTargets
Tara answered 12/2, 2018 at 19:23 Comment(0)
R
0

Adding to Chris Gong's answer about VS2017/2019 above (I don't yet have comments permission).

If VS 2019 Build Tools are installed rather than the full Visual Studio then file paths are slightly different. VCTargetsPath should then be

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\

Also note the terminating backslash - required at least in my case (TFS2017, VS2019 Build tools). Corresponding change to the PATH entry as well.

Rakia answered 12/8, 2019 at 19:31 Comment(0)
F
0

I was facing the same issue with MSBuild for VS 17

I solved this by applying the following steps:

  • In my case the Microsoft.Cpp.Default.props file was located at C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets so I created VCTragetsPath string in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 with value C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets

  • I also made my Jenkins run as an admin user

This solved my issue.

Forefend answered 14/8, 2019 at 11:47 Comment(0)
C
0

I uninstalled VSCode as I had messed up the installation part. A year ago, I had installed some other version and recently installed another. So after uninstalling everything, started from scratch. Downloaded latest version of VSCode and the build tools. Then it worked fine.

Corneous answered 10/3, 2021 at 17:18 Comment(0)
B
0

I had the problem in calling msbuild via command line and using Visual Studio 2019.

What worked for me was to clear the environment variable before calling msbuild:

set VCTargetsPath=
call %ProgramFiles(x86)%/Microsoft Visual Studio/2019/Professional/MSBuild/Current/Bin\msbuild.exe ...
Banger answered 21/5, 2021 at 16:21 Comment(0)
T
0

In my case I was using wrong version of MSBuild, because I have multiple compilers installed. I fixed this by using the full path in the command (Visual Studio 2022):

"C:\Program Files\Microsoft Visual Studio\2022\Community\Msbuild\Current\Bin\MSBuild.exe" "C:\path-to-project\myproject.vcxproj"
T answered 2/8, 2022 at 8:22 Comment(0)
B
0

My VS solution includes several projects from VS2010, adding a new VS2022 project to the solution and build in Visual Studio 2022 is fine, but building the solution in the older MSBuild.exe causes this problem. The fix is to use the same platform toolset for all projects in the solution.

Biysk answered 9/1 at 23:15 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.