Erro externo de construção do VS2013 "erro MSB4019: o projeto importado <caminho> não foi encontrado"


201

Estou criando um projeto por meio da linha de comando e não dentro do Visual Studio 2013. Observe que eu atualizei meu projeto do Visual Studio 2012 para 2013. O projeto é compilado dentro do IDE. Além disso, eu desinstalei completamente o VS2012 primeiro, reiniciei e instalei o VS2013. A única versão do Visual Studio que tenho é o 2013 Ultimate.

ValidateProjects:
    39>path_to_project.csproj(245,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    39>Done Building Project "path_to_project.csproj" (Clean target(s)) -- FAILED.

Aqui estão as duas linhas em questão:

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

A segunda linha original era a v10.0, mas eu a alterei manualmente para a v12.0.

$ (VSToolsPath) alonga do que vejo para a pasta v11.0 (VS2012), que obviamente não existe mais. O caminho deveria ter sido para a v12.0.

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\

Tentei especificar o VSToolsPath na tabela de variáveis ​​de ambiente do sistema, mas o utilitário de compilação externo ainda usa a v11.0. Tentei pesquisar no registro e isso não deu em nada.

Infelizmente, não vejo nenhuma maneira fácil de obter a linha de comando exata usada. Eu uso uma ferramenta de construção.

Pensamentos?



No meu caso, eu tive que especificar a VisualStudioVersion correta no evento de construção que estava sendo criado com o destino WebPublish.
user145400

Respostas:


250

Eu tive o mesmo problema e encontrei uma solução mais fácil

Isso ocorre porque o Vs2012 adiciona o seguinte ao arquivo csproj:

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

Você pode remover com segurança essa parte e sua solução será criada.

Como Sielu apontou, você deve garantir que o arquivo .proj comece com o <Project ToolsVersion="12"contrário. Na próxima vez que você abrir o projeto com o visual studio 2010, ele adicionará o nó removido novamente.

Caso contrário, se você precisar usar o webdeploy ou usar um servidor de construção, a solução acima não funcionará, mas você pode especificar a VisualStudioVersionpropriedade no seu script de construção:

msbuild myproject.csproj /p:VisualStudioVersion=12.0

ou edite sua definição de construção:

edite a definição de construção para especificar a propriedade <code> VisualStudioVersion </code>


1
Eu recebi o erro usando o msbuild no prompt de comando. A remoção desta parte do arquivo do projeto solucionou o problema.
Peter Hedberg

7
Eu usei essa resposta e funcionou apenas se eu assegurasse que meu arquivo * proj começasse com <Project ToolsVersion = "12" Antes de ter <Project ToolsVersion = "4" e toda vez que abri o projeto no VS, adicionei os dois nós novamente (ou seja, migrou o projeto para a versão mais recente).
Sielu

3
@giammin, eu já encontrei a solução. NÃO remova a seção do seu arquivo de projeto. Defina a versão correta das ferramentas na sua definição de construção. Isso é muito fácil de fazer. Abra sua definição de construção e vá para a página "Processo". Em seguida, no grupo "3. Avançado", você tem uma propriedade chamada "Argumentos do MSBuild". Coloque o parâmetro lá com a seguinte sintaxe "/p:VisualStudioVersion=12.0". Claro que sem as aspas. Se você tiver mais parâmetros, separe-os com um espaço e não uma vírgula. A configuração que você sugeriu para remover é usado por outras partes do visual studio em seus proces construir ...
Ralph Jansen

9
Removendo essa linha parece quebrar Web Deploy
Colin Pear

4
Eu tive o mesmo problema foi resolvido usando a propriedade /p:VisualStudioVersion=12.0, conforme recomendado acima. Obrigado
Randeep

70

Eu também tinha isso e você pode corrigi-lo definindo a versão das ferramentas na sua definição de compilação.

Isso é muito fácil de fazer. Abra sua definição de construção e vá para a página " Processo ". Em seguida, no grupo " 3. Avançado ", você tem uma propriedade chamada " Argumentos do MSBuild ". Coloque o parâmetro lá com a seguinte sintaxe

/p:VisualStudioVersion=12.0 

Se você tiver mais parâmetros, separe-os com um espaço e não uma vírgula.


1
Acabamos de concluir uma atualização do TFS 2005 para o TFS 2013 e esse foi nosso último obstáculo. Definitivamente, isso funcionou para nós e me salvou de arrancar meus cabelos. Muito obrigado! +1.
Simon Whitehead

2
Este artigo de Sayed Ibrahim Hashimi descreve o problema no Visual Studio 2010/2012. Uma compilação de linha de comando usa o formato de arquivo sln versão -1 como VisualVudioVersion. Você pode substituir esse valor na linha de comando, como Ralph descreve, ou como uma propriedade da tarefa MSBuild a partir de um script de compilação. Eu tive o mesmo problema com o Visual Studio 2013 e a substituição do VisualStudioVersion resolveu o problema.
mcdon

1
Isso funcionou para nós também. Também consideramos modificar o próprio modelo de construção, descrito aqui , que pode ser uma opção melhor se você tiver dezenas de definições de construção.
JamesQMurphy

isso funcionou para mim. Eu apaguei nos arquivos csproj qualquer referência a visualstudioversion e acrescentou que o argumento msbuild
Jhayes2118

51

Isso está intimamente relacionado, mas pode ou não corrigir um problema específico do OP. No meu caso, eu estava tentando automatizar a implantação de um site do Azure usando o VS2013. Construir e implantar via VS funciona, no entanto, o uso do MSBuild mostrou um erro semelhante nos "destinos". Acontece que o MSBuild é diferente no VS2013 e agora faz parte do VS e não o .NET Framework (consulte http://timrayburn.net/blog/visual-studio-2013-and-msbuild/ ). Basicamente, use a versão correta do MSBuild:

ANTIGO, VS2012

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

NOVO, VS2013

C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe

Mais recente, VS2015

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Mais novo ainda, o VS2017 (não testando completamente, mas descoberto - eles mudaram um pouco as coisas)

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

Isso consertou para mim. Além disso, uma resposta semelhante para uma pergunta semelhante aqui: stackoverflow.com/a/19826448/61569
Anthony F

22

Acabei de receber uma resposta do Kinook, que me deu um link :

Basicamente, preciso ligar para o seguinte antes de fazer o bulding. Acho que o Visual Studio 2013 não registra o ambiente automaticamente primeiro, mas 2012 o fez, ou eu o esqueci.

call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86

Felizmente, este post ajuda outra pessoa.


Muito obrigado, isso resolveu meu problema ao criar o nodeJS node-gypo Cpp default.propsnão foi encontrado! +1
Pogrindis 05/10

21

A solução de giammin está parcialmente incorreta. Você NÃO DEVE remover esse grupo inteiro de propriedades da sua solução. Se você fizer isso, o recurso "DeployTarget = Package" do MSBuild irá parar de funcionar. Esse recurso depende do "VSToolsPath" que está sendo definido.

<PropertyGroup>
  <!-- VisualStudioVersion is incompatible with later versions of Visual Studio.  Removing. -->
  <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> -->
  <!-- VSToolsPath is required by MSBuild for features like "DeployTarget=Package" -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
...
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

10

Eu tive esse problema para nossos destinos do FSharp (o FSharpTargetsPath estava vazio).

Muitos dos caminhos são criados com referência à versão VS.

Por várias razões, nossa compilação é executada com privilégios de sistema, e a variável de ambiente "VisualStudioVersion" foi definida apenas (pelo instalador do VS 2013) no nível "usuário" - o que é justo.

Verifique se a " VisualStudioVersion" variável de ambiente está definida como " 12.0" no nível (Sistema ou Usuário) em que você está executando.


5
Esse é provavelmente um cenário comum ao executar um servidor de compilação (como CruiseControl ou TeamCity), em que o serviço é executado em uma conta de serviço específica que pode até não ter permissões de área de trabalho interativa. Esta dica resolveu o problema para mim (VS 2013 instalado em uma instalação limpa do Server 2008 R2, com CruiseControl.NET)
David Keaveny

Onde posso ver minha "VisualStudioVersion"?
WEFX 15/06/19

@WEFX visualizar as variáveis de ambiente, selecionando Systema partir do Painel de Controle, em seguida, selecione Advanced system settingse, finalmente, cliqueEnvironment Variables
Scott

6

Executar isso na linha de comando também corrigirá o problema. SETX VisualStudioVersion "12.0"


Isso funcionou para mim e foi preferível modificar o arquivo do projeto.
Sean

4

Se você migrar o Visual Studio 2012 para 2013, abra o arquivo de projeto * .csprorj com o edior.
e verifique o elemento ToolsVersion da tag 'Project'.

Esse é o valor 4.0
Você chega a 12.0

  • De

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="4.0"
  • Para

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="12.0"

Ou Se você criar com o msbuild, basta especificar a propriedade VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0


1
O ToolsVersion não deve ser a única variável para corrigir essa mensagem de erro porque vi um projeto com o ToolsVersion que não pôde ser criado corretamente.
Patrick Desjardins

2

Eu estava usando um utilitário de construção externo. Pense em algo como formigas, se eu entendi o produto corretamente, apenas uma versão comercial. Eu tive que entrar em contato com o fabricante para obter a resposta.

Como se vê, há uma macro global no projeto, DEVSTUDIO_NET_DIR. Eu tive que mudar o caminho para .Net lá. Eles listam várias versões do visual studio como "Actions", que acabam comigo, mas todos os caminhos levam de volta a essa variável global nos bastidores. Eu listaria isso como um defeito contra o produto, se eu tivesse o que queria, a menos que estivesse perdendo algo em meu entendimento. A correção do caminho corrigiu o problema de compilação.


2

Eu tenho o Visual Studio 2013 instalado. Isso funcionou para mim:

<PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' != ''">12.0</VisualStudioVersion>`
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

Então, eu mudei a condição de ==para !=e o valor de 10.0para 12.0.


2

Eu tive um problema semelhante. Todas as soluções propostas são apenas uma solução alternativa para esse problema, mas não estão solucionando a fonte de erros. A solução @giammin não deve ser aplicada se você estiver usando o servidor de compilação tfs, pois há apenas uma funcionalidade de publicação com falha. @ cat5dev solution - resolve o problema, mas não resolve a fonte.

Tenho quase certeza de que você está usando o modelo de processo de compilação para o VS2012, como ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml esses modelos de compilação foram criados para o VS2012 e $ (VisualStudioVersion) definido como 11.0

Você deve usar o modelo de processo de compilação para o VS2013 ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml que possui $ (VisualStudioVersion) definido como 12.0

Isso funciona sem nenhuma alteração no arquivo do projeto.


2

Eu também tive o mesmo erro .. Eu fiz isso para corrigi-lo

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" />

mudar para

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

e está feito.


2

No meu caso, eu apenas comento a linha abaixo, abrindo o arquivo .csproj e fiz o truque

.<!-- <Import Project="..\PRPJECTNAME.targets" /> -->

Meu problema pode ser diferente, mas sou arrastado aqui, mas isso pode ajudar alguém.

Eu escolhi um único projeto da web da minha solução e tente abri-lo como um projeto autônomo que estava causando problemas, depois que acima de tudo, sou capaz de resolver o problema.


2

Use a versão correta do MSBuild. Defina a variável de ambiente como:

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

Isso também funcionará para projetos do VS 2019

Anteriormente, estávamos configurando-o para C:\Windows\Microsoft.NET\Framework\v4.0.30319


Usei "C: \ Arquivos de programas (x86) \ Microsoft Visual Studio \ 2019 \ Enterprise \ MSBuild \ Current \ Bin \ MSBuild.exe" em vez de "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ MSBuild. exe "e seu trabalho
ELKALAKHI Mohammed

Sim, estou usando um projeto SSDT (.sqlproj), com VisualStudioVersion = 14.0 no arquivo do projeto. Instalei o núcleo 3.1, que definiu meus envios para os alvos, pois Deus sabe apenas onde. Usando o msbuild na pasta que você sugeriu, funcionou como um encanto!
Matthew Beck

1

No meu caso, o ambiente de desenvolvimento é o VS2013 e estou usando o TFS 2010. O Build foi direcionado para o .NET 4.5.1. Eu estava configurando a compilação automática para o CI. sempre que eu tentava soluções alternativas mencionadas acima - como remover o grupo de propriedades completamente ou substituir algumas linhas, etc. minha compilação costumava acontecer no TFS, mas minha publicação no azure costumava falhar com 'MSDeploy' ou às vezes com algum erro diferente. Não fui capaz de alcançar os dois simultaneamente.

Por fim, tive que passar o argumento do MSBuild para resolver o problema.

Vá para Editar definição de construção> Processo> 3. Avançado> Argumentos do MSBuild (definido como) /p:VisualStudioVersion=12.0

Funcionou para mim.


1

Você deve copiar a pasta WebApplications de C: \ Arquivos de programas (x86) \ MSBuild \ Microsoft \ VisualStudio \ v12.0 \ para C: \ Arquivos de programas (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \


Ou copie apenas o arquivo Microsoft.WebApplication.targets de um local em que o Visual Studio 2013 está instalado.
precisa saber é o seguinte

0

você encontrará

C:\Program Files  (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets 

no arquivo csproj para o qual esse erro está aparecendo. Apenas remova isso do csproj e construa.


0

É necessário fazer apenas uma coisa para resolver o problema: atualize o TeamCity para a versão 8.1.x ou superior, pois o suporte ao Visual Studio 2012/2013 e MSBuild Tools 2013 foi introduzido apenas no TeamCity 8.1. Depois de atualizar o TeamCity, modifique a configuração da Versão das ferramentas do MSBuild na etapa de compilação e o problema desaparecerá. Para mais informações, leia aqui: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html


0

Eu - nada estava ajudando na alteração do valor v11.0 da variável VisualStudioVersion para v10.0. Alterar a variável no arquivo .csproj não. Configurá-lo através do comando promt não. Etc ...

Acabei copiando minha pasta local dessa versão específica (v11.0) para o meu servidor de compilação.


0

Eu tinha tentado todas as soluções acima e ainda não tive sorte. Eu tinha ouvido pessoas instalando o visual studio em seus servidores de compilação para corrigi-lo, mas eu tinha apenas 5 GB de espaço livre, então copiei C: \ Arquivos de Programas (x86) \ MSBuild \ Microsoft \ VisualStudio para o meu servidor de compilação e liguei por dia . Começou a trabalhar depois disso, usando o team city 9.xe o visual studio 2013.


0

Baseado no TFS 2015 Build Server

Se você combater esse erro ... Error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Abra o .csprojarquivo do projeto nomeado na mensagem de erro e comente a seção abaixo

<!-- <PropertyGroup> --> <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> --> <!-- <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath> --> <!-- </PropertyGroup> -->


0

Eu recebi esse erro ao instalar alguns componentes do VS. Infelizmente, nenhuma dessas respostas não me ajudou. Uso o TFS para o desenvolvimento de comandos e não tenho permissões para editar a definição de compilação. Resolvi esse problema excluindo variáveis ​​de ambiente que chamavam VS110COMNTOOLSe VS120COMNTOOLS. Eu acho que foi instalado com meus componentes do VS.


0

Descobri que estava faltando a pasta WebApplications no meu PC local, não instalei com o Visual Studio 2017 como havia quando eu estava usando 2012.


0

No meu caso, eu estava usando a versão errada do MSBuild.exe .

A versão que você precisa usar depende da versão do Visual Studio usada para criar seu projeto. No meu caso, eu precisava do 14.0 (depois de usar o Visual Studio 2015).

Isso foi encontrado em:

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Você pode procurar em:

C:\Program Files (x86)\MSBuild

Para encontrar outras versões.

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.