Why does MSBuild look in C:\ for Microsoft.Cpp.Default.props instead of c:\Program Files (x86)\MSBuild? ( error MSB4019)

Question

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.

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... — Florian Winter, Oct 11 '18 at 14:49

score 79 · Answer 1 · answered Dec 24 '14 at 03:28

79

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

answered Dec 24 '14 at 03:28

Jeff

791
5
2

This helped me to install the oracledb node package. I followed instructions on https://community.oracle.com/docs/DOC-931127 and even so I got error MSB4019, which I fixed with this answer. – Pedro Otero Feb 04 '16 at 16:14
4

PowerShell version: `[Environment]::SetEnvironmentVariable("VCTargetsPath", "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140", "Machine")` – fiat Oct 24 '18 at 03:28
Helped with path ended with 'v4.0' – Alexander Jul 04 '19 at 09:39
there's also the 'setx' command with /m flag for windows server – john k May 04 '22 at 13:28

score 52 · Accepted Answer · edited May 23 '17 at 12:26

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.

edited May 23 '17 at 12:26

Community

1
1

answered Apr 25 '13 at 18:27

Peter Kahn

12,364
20
77
135

12

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` – elmotec Mar 20 '15 at 14:50
12

for me it's worked only with this set `VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v120` – ygaradon Jun 04 '15 at 17:59
Building [eventstore](https://github.com/eventstore/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` – Plato Jul 30 '15 at 15:40
1

@cmm-user HKLM stands for `HKEY_LOCAL_MACHINE` you should definitely have it in regedit – Michael Johnston Feb 17 '16 at 21:44
4

VCTargetsPath is not a key, but a String Value! – John Smith May 26 '16 at 07:00
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 – Green Nov 16 '16 at 13:43
@Green 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. – Peter Kahn Nov 16 '16 at 13:58
6

For me it was now `set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140` – Daniel Gray Aug 02 '17 at 08:19
It worked for me with setting BOTH the key string in the registry and the environment variable like @ygaradon 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` – jmpp Aug 27 '18 at 10:32
This answer is incorrect. I already had these exact registry values, and I'm still getting these errors. – Andrew Koster Mar 17 '20 at 20:32

score 27 · Answer 3 · answered Jan 03 '17 at 23:22

27

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!

answered Jan 03 '17 at 23:22

Luke

1,872
20
31

1

Good thing but does not work for Azure unfortunately. – Aleksey Kontsevich Dec 12 '17 at 12:52
6

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: https://github.com/nodejs/node-gyp – eliotRosewater Apr 02 '18 at 22:44

score 23 · Answer 4 · edited Jun 20 '20 at 09:12

23

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

edited Jun 20 '20 at 09:12

Community

1
1

answered Jan 19 '19 at 20:09

Chris Gong

8,031
4
30
51

1

In mine, VCTargetPath was C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets – Madura Pradeep Jun 09 '19 at 05:50
2

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. – MSalters Mar 03 '20 at 16:44
2

`'vswhere.exe' is not recognized as an internal or external command, operable program or batch file.` – Andrew Koster Mar 17 '20 at 20:45
1

@AndrewKoster vswhere seems to be in C:\ProgramFiles (x86)\Microsoft Visual Studio\Installer\vswhere.exe – bluish Oct 07 '20 at 07:13
https://learn.microsoft.com/en-us/cpp/build/reference/msbuild-visual-cpp-overview?view=msvc-170&viewFallbackFrom=vs-2019 – BigChief Dec 02 '21 at 19:37

score 14 · Answer 5 · answered Apr 25 '13 at 11:22

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

Visual Studio 2010
Windows SDK 7.1
Visual Studio 2010 SP1
Visual C++ 2010 SP1 Compiler Update for the Windows SDK 7.1

answered Apr 25 '13 at 11:22

xverges

4,608
1
39
60

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 – Peter Kahn Apr 25 '13 at 18:24

score 6 · Answer 6 · answered Apr 18 '13 at 21:30

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)

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 — Peter Kahn, Apr 19 '13 at 16:51

score 6 · Answer 7 · answered Jan 22 '17 at 02:05

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 \

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. — Lars Pellarin, Feb 12 '19 at 21:19
For me, this helped fix it - a script I was using was "helpfully" finding the wrong msbuild.exe and calling it explicitly. — Scovetta, May 15 '20 at 07:15

score 5 · Answer 8 · answered Jul 05 '18 at 11:17

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

answered Jul 05 '18 at 11:17

Sjs

213
1
3
16

Done this. Restarted the cmd after, but doesn't fix the issue. – Dan Jan 29 '19 at 19:10

Florian Winter · Answer 9 · 2020-12-01T08:40:19.017

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://stackoverflow.com/a/41786593/2279059 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:

If you don't want to reinstall your OS but try to fix your registry instead, you may want to try this answer: https://stackoverflow.com/a/38503503/2279059

Konstantin Ineshin · Answer 10 · 2018-11-12T16:51:11.323

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\\'))"

score 2 · Answer 11 · edited May 23 '17 at 12:03

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.

score 2 · Answer 12 · edited Oct 27 '18 at 02:37

2

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

C:\Program Files\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0

edited Oct 27 '18 at 02:37

Samuel Liew

76,741
107
159
260

answered Sep 28 '18 at 13:09

sowmiya lakshmi

29
2

1

which path should i set? – Nageshwar Reddy Pandem Apr 25 '19 at 18:03

score 2 · Answer 13 · answered Dec 17 '19 at 11:42

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.

score 1 · Answer 14 · answered Feb 13 '20 at 14:55

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.

jxramos · Answer 15 · 2015-12-02T05:04:08.820

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.

score 0 · Answer 16 · answered Apr 01 '16 at 10:34

0

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

answered Apr 01 '16 at 10:34

user2818782

736
8
18

score 0 · Answer 17 · answered May 29 '17 at 15:12

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.

score 0 · Answer 18 · answered Feb 12 '18 at 19:23

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

answered Feb 12 '18 at 19:23

Hugh

1,133
1
12
27

score 0 · Answer 19 · answered Aug 12 '19 at 19:31

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.

score 0 · Answer 20 · edited Aug 14 '19 at 14:22

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.

score 0 · Answer 21 · answered Mar 10 '21 at 17:18

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.

score 0 · Answer 22 · edited May 22 '21 at 06:34

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 ...

edited May 22 '21 at 06:34

C. Peck

3,641
3
19
36

answered May 21 '21 at 16:21

bomtom

85
1
6

score 0 · Answer 23 · answered Aug 02 '22 at 08:22

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"

Why does MSBuild look in C:\ for Microsoft.Cpp.Default.props instead of c:\Program Files (x86)\MSBuild? ( error MSB4019)

23 Answers23

For Visual Studio 2017 and 2019 on Windows 10

Linked