Por que o MSBuild procura em C: \ Microsoft.Cpp.Default.props em vez de c: \ Arquivos de Programas (x86) \ MSBuild? (erro MSB4019)

124

Quando executo o msbuild para criar um projeto vc2010, recebo o seguinte erro:

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 localizado c: \ Arquivo de Programa (x86) \ MSBuild
  • HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolVersions \ V4.0 VCTargetsPath definido como $ (MSBuildExtensionsPath32) \ Microsoft.Cpp \ v4.0 \
  • ao executar o msbuild / verbosity: diag, como bom sistema mostra MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath definido como Ambiente no início da compilação
  • definir MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath definido como variáveis ​​de ambiente no shell não faz com que sejam mostrados como Ambiente no início da compilação

Correções tentadas

  • .Net 4.5 não desinstalado, .net 4.0 reparado
  • Defina MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath nas variáveis ​​do sistema.

Parece que o MSBuildExtensionsPath32 não está sendo definido corretamente e a configuração do MSBuildExtensionsPath não ajuda

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

Entre em contato se tiver alguma idéia sobre o que está bloqueando a configuração adequada dessa variável.

msbuild 
— Peter Kahn
fonte
6
Ótimo! Outra pergunta sobre um erro resultante de uma instalação corrompida do Visual Studio com centenas de soluções alternativas que funcionam apenas em alguns cenários selecionados ...
— Florian Winter

Respostas:

75

Eu tive esse problema ao publicar um aplicativo cocos2d-x usando sua ferramenta de linha de comando, que chama MSBuild. Estou usando o Win 7 de 64 bits, VS2013 express, cocos2d-x versão 3.3, .NET Framework 4.5 instalado.

Corrigi o problema definindo o seguinte antes de executar o comando de publicação cocos.py:

SET VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120
— Jeff
fonte
Isso me ajudou a instalar o pacote do nó oracledb. Segui as instruções em community.oracle.com/docs/DOC-931127 e, mesmo assim, recebi o erro MSB4019, que corrigi com esta resposta.
— Pedro Otero
1
Versão do PowerShell:[Environment]::SetEnvironmentVariable("VCTargetsPath", "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140", "Machine")
— fiat
Ajudado com o caminho terminado com 'v4.0'
— Alexander
50

Para aqueles que não seguiram a ordem proscrita da MS (consulte a resposta de Xv ), você ainda pode resolver o problema.

O MSBuild usa o VCTargetsPathpara localizar propriedades padrão do cpp, mas não pode porque o registro não possui esse Valor da String.

Verifique o valor da string

  • Iniciar regedit
  • Navigator para HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Inspecione a VCTargetsPathchave. O valor deve = " $(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

Consertar

  • Inicie o regedit Navigator para HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Adicionar valor da string VCTargetsPath
  • Defina Valor como " $(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

Nota: HKLMsignifica HKEY_LOCAL_MACHINE.

— Peter Kahn
fonte
12
A entrada do registro já estava lá para mim. Eu tive que definir uma variável de ambiente com esse nome definido como o valor no registro para superar essa:set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0
— elmotec 20/15/15
12
Para mim é trabalhado apenas com este conjuntoVCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v120
— ygaradon
1
@ HKLM pelo usuário cmm significa HKEY_LOCAL_MACHINEque você definitivamente deveria tê-lo em regedit
— Michael Johnston
4
VCTargetsPath não é uma chave, mas um Valor de String!
— John Smith
5
Para mim, foi agoraset VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140
— Daniel Grey
26

Eu tive o mesmo problema recentemente e depois de instalar pacotes diferentes em ordem diferente, estava ficando muito confuso. Então encontrei este repositório - https://github.com/felixrieseberg/windows-build-tools

npm install --global windows-build-tools

Ele instala as ferramentas Python e VS Build necessárias para compilar a maioria dos módulos de nós. Funcionou um prazer!

— Lucas
fonte
1
Infelizmente, infelizmente não funciona para o Azure.
— Aleksey Kontsevich
6
Para aqueles que podem estar tendo um problema como eu. Eu precisava da --productionopção. npm install --global --production windows-build-tools De acordo com o nó-gyp instruções de instalação: github.com/nodejs/node-gyp
— eliotRosewater
15

Para Visual Studio 2017 e 2019 no Windows 10

Muitas das respostas aqui se aplicam a versões mais antigas do Visual Studio. O que funcionou para mim, se estiver usando a versão da Comunidade do Visual Studio 2017, foi definir uma variável de ambiente chamadaVCTargetsPath e atribuir a ela um valor de

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

Se estiver usando a versão da Comunidade do Visual Studio 2019,

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

Outras respostas aqui configuram essa variável como c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140 mas notei que na instalação do meu visual studio, não havia uma pasta chamada Microsoft.Cpp na minha pasta MSBuild. Portanto, lembre-se disso e do fato de que o caminho acima é para a versão comunitária do Visual Studio 2017.

Além disso, verifique se o caminho do MSBuild nas variáveis ​​de ambiente aponta para a versão correta do MSBuild se você estiver usando a versão da Comunidade do Visual Studio 2017,

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

Se você estiver usando a versão da Comunidade do Visual Studio 2019,

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin
— Chris Gong
fonte
1
Na minha, VCTargetPath era C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ buildtools \ Common7 \ IDE \ VC \ VCTargets
— Madura Pradeep
1
Também pode haver Microsoft Visual Studio\2019\BuildToolsvariações semelhantes - e suponho que, em vez de BuildTools e Community, você também possa ter o Professional e o Enterprise. vswhere.exe -products * -property installationPathprocurará todas as combinações e retornará os locais de todos os produtos instalados.
— MSalters 3/03
1
'vswhere.exe' is not recognized as an internal or external command, operable program or batch file.
— Andrew Koster
13

A instalação da atualização do compilador do Microsoft Visual C ++ 2010 Service Pack 1 para o Windows SDK 7.1 corrigiu os MSB4019erros que eu estava adquirindo no Windows7 x64.

O leia-me dessa atualização afirma que o pedido recomendado é

  1. Visual Studio 2010
  2. Windows SDK 7.1
  3. Visual Studio 2010 SP1
  4. Atualização do compilador do Visual C ++ 2010 SP1 para o Windows SDK 7.1
— xverges
fonte
Ah ok. Eu descobri a correção para isso. Adicione a chave do Registro ausente. Vou postar e atualizar meus documentos de configuração para seguir esta ordem
— Peter Kahn
6

Em sistemas de 64 bits, o MSBuild padroniza as seguintes propriedades (onde C: é SystemDrive):

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

Caso contrário, significa que você tem alguns destinos personalizados de substituição de terceiros instalados ou a instalação do MSBuild está corrompida.

Coisas para experimentar:

  • Reparar a instalação do .NET
  • Aplicar o Visual Studio Service Pack mais recente
  • Defina MSBuildExtensionsPathmanualmente como acima (observe a x86peça em máquinas de 64 bits)
— KMoraz
fonte
2
Obrigado, mas ainda não foram definidos depois: 1) repare .net 4.5, 2) desinstale .net 4.5 e repare 4.0. Se eu colocá-las manualmente no ambiente que não quer trabalhar
— Peter Kahn
5

Eu tive esse problema na edição do Visual Studio 2015. Quando usei o cmake para gerar um projeto, esse erro apareceu.

erro MSB4019: O projeto importado "D: \ Microsoft.Cpp.Default.props" não foi encontrado

Corrigi-o adicionando uma String

VCTargetsPath

com valor

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

no caminho do registro

HKLM \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 14.0

— Sjs
fonte
Feito isso. Reiniciou o cmd depois, mas não resolve o problema.
— Dan
4

MSBuild em uma ferramenta de compilação independente que é frequentemente empacotada com outras ferramentas. Pode ter sido instalado no seu computador com .NET (versões mais antigas), Visual Studio (versões mais recentes) ou mesmo Team Foundation Build.

O MSBuild precisa de arquivos de configuração, compiladores etc. (um ToolSet) que corresponda à versão do Visual Studio ou TFS que o usará, bem como à versão do .NET na qual o código-fonte será compilado.

Dependendo de como o MSBuild foi instalado, os arquivos de configuração podem estar em um ou mais desses caminhos.

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

Conforme descrito em outras respostas, um item de registro e / ou ponto de variável ambiental deve estar no caminho do ToolSet.

  • A chave VCTargetsPath em HKLM \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0
  • A variável de ambiente VCTargetsPath.

Ocasionalmente, uma operação como a instalação de uma ferramenta deixa o registro e / ou a variável ambiental configurada incorretamente. As outras respostas são todas variações sobre como corrigi-las.

A única coisa que tenho a acrescentar é que a variável ambiental não funcionou para mim quando parei o final \

— mmesser314
fonte
Este! Tivemos problemas em nosso agente de construção sem a instalação completa do VS2017. Reinstalamos a "Carga de trabalho" com um determinado conjunto de ferramentas de VC - não o componente individual, e ele fez uma instalação correta. Suspeitamos que o instalador do Visual Studio não tenha colocado o conjunto de ferramentas correto v141 no VS2017 durante nossa instalação de seleção de componente personalizada.
— Lars Pellarin
Para mim, isso ajudou a corrigi-lo - um script que eu estava usando era "útil" para encontrar o msbuild.exe errado e chamá-lo explicitamente.
— Scovetta
4

As entradas do registro para a chave MSBuild funcionaram bem para mim. É importante lembrar que isso deve ser feito para ramificações de 64 ou 32 bits, dependendo da versão do MSBuild que você executa. Eu não recomendaria usar variáveis ​​de ambiente, pois isso pode causar problemas em diferentes versões do MSBuild.

Este arquivo do registro corrige isso nos dois 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
fonte
3

EDIT: Isso se aplica a versões mais antigas do Visual Studio / MSBuild (especificamente MSVC2015?). Com versões mais modernas, o MSBuild é incluído no Visual Studio Build Tools 2019, e os compiladores estão localizados em locais diferentes e detectados de maneiras diferentes.

Isso ocorre devido a uma incompatibilidade dos conjuntos de ferramentas e configurações do Registro do MSBuild instalados. Isso pode acontecer se você fez um ou mais dos seguintes procedimentos:

  • Instale várias versões do Visual Studio na ordem errada
  • Desinstale uma ou mais versões do Visual Studio
  • Faça manualmente alterações ou modificações no registro da instalação do Visual Studio

A única solução segura e confiável é reinstalar o sistema operacional. Se seu projeto precisar de várias versões do Visual Studio para criar, instale a versão mais antiga primeiro . Em seguida, corrija seu código para poder usar uma única ferramenta para construí-lo, ou você ou seus colegas voltarão à mesma bagunça em breve.

Se isso não for uma opção para você, leia primeiro https://stackoverflow.com/a/41786593/2279059 para obter uma melhor compreensão do problema e o que as várias "soluções" realmente fazem. Em seguida, dependendo da versão e configuração do Visual Studio, uma das outras respostas ou variações delas poderá ajudar.

Mais algumas dicas:

— Florian Winter
fonte
2

Instalar a atualização do compilador do Microsoft Visual C ++ 2010 Service Pack 1 para o Windows SDK 7.1 funcionou para mim. No entanto, tive problemas com a atualização porque eu já tinha o VS 2010 e o VS 2010 SP1 instalados. Conforme mencionado por Xv acima, o arquivo readme.htm contém soluções para os problemas mais comuns de instalação na seção "Problemas conhecidos". Eu seguia as instruções no readme.htm e reiniciava sua máquina após cada tentativa de solução de problemas, porque algumas instalações gravam no seu registro.

— aquecedor
fonte
2

No meu caso, adicionei uma variável de ambiente VCTargetPathcom path

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

('\' no final é crucial, pois os arquivos de solução do projeto têm uma referência ao arquivo "Microsoft cpp target").

Além disso, a partir do Visual Studio 2017 MSBUILD é fornecido no Visual Studio - portanto, é PATH variablenecessário atualizar o

C: \ Arquivos de programas (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ MSBuild \ 15.0 \ Bin

A atualização VCTargetPathe as PATHvariáveis ​​e construção do MSBUILD corrigiram o erro.

— Arjun Krishna
fonte
0

Me deparei com esse erro escrevendo um script de compilação que colocaria o MSBuild no% PATH% depois de procurar recursivamente na pasta C: \ Windows \ Microsoft.NET os arquivos MSBuild.exe encontrados. O último hit encontrado foi o diretório que foi colocado no caminho. Como o dircomando atingia a Framework64pasta depois que Frameworkeu estava recebendo um dos MSBuilds de 64 bits colocados no meu caminho. Eu estava tentando criar uma solução do Visual Studio 2010 e acabei alterando minha sequência de pesquisa de C:\Windows\Microsoft.NETpara C:\Windows\Microsoft.NET\Frameworkpara que eu terminasse com um MSBuild.exe de 32 bits. Agora meu arquivo de solução é compilado.

— jxramos
fonte
0

Acabei de adicionar VCTargetsPath={c:\...}como uma variável de ambiente ao meu trabalho no Hudson.

— user2818782
fonte
0

Para o registro, o arquivo Microsoft.Cpp.Default.propspode modificar a var env VCTargetsPathe tornar incorretos os usos subsequentes dessa var. Eu tive esse problema e o resolvi definindo VCTargetsPath10e VCTargetsPath11com o mesmo valor que VCTargetsPath.

Isso deve ser adaptado de acordo com a versão do VS que você está usando.

— STM
fonte
0

Estou vendo isso em um ambiente VS2017. Meu script de construção chama VsDevCmd.batprimeiro e, para resolver esse problema, defino a VCTargetsPathvariável de ambiente VsDevCmdantes e depois de chamar o MSBuild:

set VCTargetsPath=%VCIDEInstallDir%VCTargets
— Hugh
fonte
0

Adicionando à resposta de Chris Gong sobre o VS2017 / 2019 acima (ainda não tenho permissão para comentários).

Se o VS 2019 Build Tools estiver instalado em vez do Visual Studio completo, os caminhos dos arquivos serão ligeiramente diferentes. O VCTargetsPath deve então ser

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

Observe também a barra invertida final - necessária pelo menos no meu caso (ferramentas de compilação TFS2017, VS2019). Alteração correspondente à entrada PATH também.

— Lars V
fonte
0

Eu estava enfrentando o mesmo problema com o MSBuild for VS 17

Resolvi isso aplicando as seguintes etapas:

  • No meu caso, o Microsoft.Cpp.Default.propsarquivo estava localizado em, C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets então eu criei uma VCTragetsPathstring no registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0com valor C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets

  • Também fiz meu Jenkins funcionar como usuário administrador

Isso resolveu meu problema.

— Hemant
fonte
0

Em vez de definir um caminho fixo, tente isso na linha de comando pós-compilação primeiro:

SET VCTargetsPath=$(VCTargetsPath)

A variável '$ (VCTargetsPath)' parece ser uma macro visual-studio relacionada ao c ++ que não é mostrada em c # -sdk-projects como uma macro, mas ainda está disponível lá.

— Sam
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.