¿Por qué MSBuild busca en C: \ Microsoft.Cpp.Default.props en lugar de c: \ Program Files (x86) \ MSBuild? (error MSB4019)

124

Cuando ejecuto msbuild para construir un proyecto vc2010 me sale el siguiente 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 ubicado c: \ Archivo de programa (x86) \ MSBuild
  • HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolVersions \ V4.0 VCTargetsPath establecido en $ (MSBuildExtensionsPath32) \ Microsoft.Cpp \ v4.0 \
  • al ejecutar msbuild / verbosity: diag como buen sistema muestra MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath establecido como Entorno al inicio de la compilación
  • establecer MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath como variables de entorno en el shell no hace que se muestren como Entorno al inicio de la compilación

Arreglos intentados

  • Desinstalado .net 4.5, reparado .net 4.0
  • Establezca MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath en las variables del sistema.

Parece que MSBuildExtensionsPath32 no se está configurando correctamente y la configuración de MSBuildExtensionsPath no ayuda

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

Avíseme si tiene alguna idea sobre qué está bloqueando la configuración adecuada de esta variable.

Peter Kahn
fuente
66
¡Excelente! Otra pregunta sobre un error resultante de una instalación corrupta de Visual Studio con cientos de soluciones alternativas que cada una solo funciona en unos pocos escenarios seleccionados ...
Florian Winter

Respuestas:

75

Tengo este problema cuando publico una aplicación cocos2d-x usando su herramienta de línea de comando, que llama a MSBuild. Estoy usando Win 7 de 64 bits, VS2013 express, cocos2d-x versión 3.3, .NET Framework 4.5 instalado.

Solucioné el problema configurando lo siguiente antes de ejecutar el comando de publicación cocos.py:

SET VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120
Jeff
fuente
Esto me ayudó a instalar el paquete del nodo oracledb. Seguí las instrucciones en community.oracle.com/docs/DOC-931127 y aun así recibí el error MSB4019, que solucioné con esta respuesta.
Pedro Otero
1
Versión de PowerShell:[Environment]::SetEnvironmentVariable("VCTargetsPath", "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140", "Machine")
fiat
Ayudado con el camino terminado con 'v4.0'
Alexander
50

Para aquellos que no siguieron el orden proscrito de MS (ver la respuesta de Xv ) todavía pueden solucionar el problema.

MSBuild usa el VCTargetsPathpara localizar las propiedades de cpp predeterminadas, pero no puede porque el registro carece de este valor de cadena.

Verifique el valor de la cadena

  • Lanzamiento regedit
  • Navegador a HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Inspeccionar la VCTargetsPathllave. El valor debería = " $(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

Arreglar

  • Inicie regedit Navigator para HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Agregar valor de cadena VCTargetsPath
  • Establecer valor en " $(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

Nota: HKLMsignifica HKEY_LOCAL_MACHINE.

Peter Kahn
fuente
12
La entrada del registro ya estaba allí para mí. Tuve que definir una variable de entorno con ese nombre establecido en el valor en el registro para set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0
superarlo
12
para mí solo funcionó con este setVCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v120
ygaradon
1
@ cmm-user HKLM significa HKEY_LOCAL_MACHINEque definitivamente deberías tenerlo en regedit
Michael Johnston
44
¡VCTargetsPath no es una clave, sino un valor de cadena!
John Smith
55
Para mí fue ahoraset VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140
Daniel Gray
26

Recientemente tuve el mismo problema y, después de instalar diferentes paquetes en un orden diferente, se estaba volviendo muy complicado. Entonces encontré este repositorio: https://github.com/felixrieseberg/windows-build-tools

npm install --global windows-build-tools

Instala las herramientas Python y VS Build necesarias para compilar la mayoría de los módulos de nodo. ¡Funcionó de maravilla!

Luke
fuente
1
Buena cosa pero desafortunadamente no funciona para Azure.
Aleksey Kontsevich
66
Para aquellos que podrían estar teniendo un problema como yo. Necesitaba la --productionopción npm install --global --production windows-build-tools Según las instrucciones de instalación de node- gyp
eliotRosewater
15

Para Visual Studio 2017 y 2019 en Windows 10

Muchas de las respuestas aquí se aplican a versiones anteriores de Visual Studio. Lo que funcionó para mí, si usaba la versión Visual Studio 2017 Community, era establecer una variable de entorno llamada VCTargetsPathy darle un valor de

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

Si usa la versión Visual Studio 2019 Community,

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

Otras respuestas aquí configuraron esta variable c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140pero noté que en mi instalación de Visual Studio, no había una carpeta llamada Microsoft.Cpp en mi carpeta MSBuild. Tenga esto en cuenta y el hecho de que la ruta anterior es para la versión comunitaria de Visual Studio 2017.

Además, asegúrese de que su ruta de MSBuild en las variables de entorno apunte a la versión correcta de MSBuild si está utilizando la versión Visual Studio 2017 Community,

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

Si está utilizando la versión Visual Studio 2019 Community,

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin
Chris Gong
fuente
1
En el mío, VCTargetPath fue C: \ Archivos de programa (x86) \ Microsoft Visual Studio \ 2017 \ BuildTools \ Common7 \ IDE \ VC \ VCTargets
Madura Pradeep
1
También podría ser Microsoft Visual Studio\2019\BuildToolso variaciones similares, y supongo que en lugar de BuildTools y Community también podría tener Professional y Enterprise. vswhere.exe -products * -property installationPathbuscará todas las combinaciones y devolverá las ubicaciones de todos los productos instalados.
MSalters
1
'vswhere.exe' is not recognized as an internal or external command, operable program or batch file.
Andrew Koster,
13

La instalación de la actualización del compilador de Microsoft Visual C ++ 2010 Service Pack 1 para Windows SDK 7.1 solucionó los MSB4019errores que estaba generando en Windows7 x64.

El archivo Léame de esa actualización indica que el orden recomendado es

  1. Visual Studio 2010
  2. Windows SDK 7.1
  3. Visual Studio 2010 SP1
  4. Actualización del compilador Visual C ++ 2010 SP1 para Windows SDK 7.1
xverges
fuente
Oh ok Descubrí la solución para esto. Agregue la clave de registro que falta. Lo publicaré y actualizaré mis documentos de configuración para seguir este orden
Peter Kahn
6

En sistemas de 64 bits, MSBuild usa las siguientes propiedades (donde C: es SystemDrive):

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

Si no es así, significa que tiene instalados algunos objetivos de anulación de terceros personalizados o que su instalación de MSBuild está dañada.

Cosas para probar:

  • Reparación de instalación .NET
  • Aplicar el último Service Pack de Visual Studio
  • Establezca MSBuildExtensionsPathmanualmente como se indica arriba (observe la x86parte en máquinas de 64 bits)
KMoraz
fuente
2
Gracias, pero aún no se han configurado después de: 1) reparar .net 4.5, 2) desinstalar .net 4.5 y reparar 4.0. Si los configuro manualmente en el entorno tampoco funciona
Peter Kahn
5

Tuve este problema en la edición Visual Studio 2015. Cuando usé cmake para generar un proyecto, apareció este error.

error MSB4019: no se encontró el proyecto importado "D: \ Microsoft.Cpp.Default.props"

Lo arreglé agregando una cadena

VCTargetsPath

con valor

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

en la ruta de registro

HKLM \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 14.0

Sjs
fuente
Hecho esto Reinició el cmd después, pero no soluciona el problema.
Dan
4

MSBuild en una herramienta de compilación independiente que frecuentemente se incluye con otras herramientas. Es posible que se haya instalado en su computadora con .NET (versiones anteriores), Visual Studio (versiones más recientes) o incluso Team Foundation Build.

MSBuild necesita archivos de configuración, compiladores, etc. (un conjunto de herramientas) que coincida con la versión de Visual Studio o TFS que lo usará, así como la versión de .NET contra la cual se compilará el código fuente.

Dependiendo de cómo se instaló MSBuild, los archivos de configuración pueden estar en una o más de estas rutas.

  • C: \ Archivos de programa (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \
  • C: \ Archivos de programa (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \ V120 \
  • C: \ Archivos de programa (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \ V140 \

Como se describe en otras respuestas, un elemento de registro y / o un punto variable ambiental debe estar en la ruta del conjunto de herramientas.

  • La clave VCTargetsPath en HKLM \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0
  • La variable de entorno VCTargetsPath.

Ocasionalmente, una operación como instalar una herramienta dejará el registro y / o la variable de entorno configurada incorrectamente. Las otras respuestas son todas variaciones para solucionarlos.

Lo único que tengo que agregar es que la variable ambiental no me funcionó cuando dejé el final \

mmesser314
fuente
¡Esta! Tuvimos problemas con nuestro agente de compilación sin una instalación VS2017 completa. Reinstalamos la "Carga de trabajo" con un conjunto de herramientas de VC dado, no el componente individual, e hizo una instalación correcta. Sospechamos que el instalador de Visual Studio no colocó el conjunto de herramientas correcto v141 en VS2017 durante nuestra instalación de selección de componentes personalizados.
Lars Pellarin
Para mí, esto ayudó a solucionarlo: una secuencia de comandos que estaba usando fue "útil" para encontrar el msbuild.exe incorrecto y llamarlo explícitamente.
Scovetta
4

Las entradas de registro para la clave MSBuild me funcionaron bien. Es importante recordar que debe hacerse para ramas de 64 bits o 32 bits, dependiendo de la versión de MSBuild que ejecute. No recomendaría usar variables de entorno ya que puede causar problemas en diferentes versiones de MSBuild.

Este archivo de registro corrige eso para ambos casos:

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\\'))"
Konstantin Ineshin
fuente
3

Nada más funcionó para mí excepto, establecer el camino como:

C:\Program Files\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0
sowmiya lakshmi
fuente
¿Qué camino debo establecer?
Nageshwar Reddy Pandem
3

EDITAR: Esto se aplica a versiones anteriores de Visual Studio / MSBuild (¿específicamente MSVC2015?). Con versiones más modernas, MSBuild se incluye en Visual Studio Build Tools 2019, y los compiladores se encuentran en diferentes lugares y se detectan de diferentes maneras.

Esto se debe a una falta de coincidencia de los conjuntos de herramientas MSBuild instalados y la configuración del registro. Puede suceder si hiciste uno o más de los siguientes:

  • Instale varias versiones de Visual Studio en el orden incorrecto
  • Desinstale una o más versiones de Visual Studio
  • Realizar manualmente cambios o modificaciones en el registro de la instalación de Visual Studio

La única solución segura y confiable es reinstalar su sistema operativo. Si su proyecto necesita varias versiones de Visual Studio para compilar, instale primero la versión más antigua . Luego arregle su código para que pueda usar una sola herramienta para construirlo, o usted o sus colegas volverán a estar en el mismo lío pronto.

Si esta no es una opción para usted, primero lea https://stackoverflow.com/a/41786593/2279059 para comprender mejor el problema y lo que realmente hacen las diversas "soluciones". Luego, dependiendo de su versión y configuración de Visual Studio, una de las otras respuestas o variaciones de ellas eventualmente puede ayudar.

Algunas sugerencias más:

Florian Winter
fuente
2

Instalar Microsoft Visual C ++ 2010 Service Pack 1 Compiler Update para Windows SDK 7.1 funcionó para mí. Sin embargo, tuve problemas con la actualización porque ya tenía VS 2010 y VS 2010 SP1 instalados. Como mencionó Xv anteriormente, el archivo readme.htm contiene soluciones para los problemas de instalación más comunes en la sección "Problemas conocidos". Seguiría las instrucciones en el archivo readme.htm y reiniciaría su máquina después de cada intento de solución de problemas porque algunas instalaciones escriben en su registro.

Heatfan
fuente
2

En mi caso, he agregado una variable de entorno VCTargetPathcon ruta

"C: \ Archivos de programa (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ Common7 \ IDE \ VC \ VCTargets \"

('\' al final es crucial, ya que los archivos de la solución del proyecto tienen una referencia al archivo de "objetivos de Microsoft cpp".

Además, a partir de Visual Studio 2017, MSBUILD viene dentro de Visual Studio, por lo que las PATH variablenecesidades deben actualizarse con

C: \ Archivos de programa (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ MSBuild \ 15.0 \ Bin

La actualización VCTargetPathy las PATHvariables y construcción de MSBUILD repararon el error.

Arjun Krishna
fuente
0

Encontré este error al escribir un script de compilación que pondría a MSBuild en% PATH% después de buscar de forma recursiva en la carpeta C: \ Windows \ Microsoft.NET los archivos MSBuild.exe encontrados. El último resultado encontrado fue el directorio que se colocó en la ruta. Dado que el dircomando golpeó la Framework64carpeta después de que Frameworkrecibí uno de los MSBuilds de 64 bits en mi camino. Estaba tratando de construir una solución de Visual Studio 2010 y terminé alterando mi cadena de búsqueda de C:\Windows\Microsoft.NETa C:\Windows\Microsoft.NET\Frameworkpara que terminara con un MSBuild.exe de 32 bits. Ahora mi archivo de soluciones se construye.

jxramos
fuente
0

Acabo de agregar VCTargetsPath={c:\...}como una variable de entorno a mi trabajo Hudson.

usuario2818782
fuente
0

Para el registro, el archivo Microsoft.Cpp.Default.propspuede modificar la variable de entorno VCTargetsPathy hacer incorrectos los usos posteriores de esa variable. Tuve ese problema y lo resolví estableciendo VCTargetsPath10y VCTargetsPath11con el mismo valor queVCTargetsPath .

Esto debe adaptarse de acuerdo con la versión VS que está utilizando.

STM
fuente
0

Estoy viendo esto en un entorno VS2017. Mi script de compilación llama VsDevCmd.batprimero, y para resolver este problema configuro la VCTargetsPathvariable de entorno después VsDevCmdy antes de llamar a MSBuild:

set VCTargetsPath=%VCIDEInstallDir%VCTargets
Hugh
fuente
0

Agregando a la respuesta de Chris Gong sobre VS2017 / 2019 arriba (todavía no tengo permiso de comentarios).

Si se instalan VS 2019 Build Tools en lugar de Visual Studio completo, las rutas de archivo son ligeramente diferentes. VCTargetsPath debería ser

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

También tenga en cuenta la barra diagonal inversa de terminación: requerida al menos en mi caso (TFS2017, VS2019 Build tools). Cambio correspondiente a la entrada PATH también.

Lars V
fuente
0

Estaba enfrentando el mismo problema con MSBuild para VS 17

Resolví esto aplicando los siguientes pasos:

  • En mi caso, el Microsoft.Cpp.Default.propsarchivo estaba ubicado en, C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets así que creé una VCTragetsPathcadena en el registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0con valor C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets

  • También hice que mi Jenkins se ejecutara como usuario administrador

Esto resolvió mi problema.

Hemant
fuente
0

En lugar de establecer una ruta fija, intente esto primero en su línea de comandos posterior a la compilación:

SET VCTargetsPath=$(VCTargetsPath)

La variable '$ (VCTargetsPath)' parece ser una macro visual-studio relacionada con c ++ que no se muestra en c # -sdk-projects como una macro, pero aún está disponible allí.

Sam
fuente