Microsoft.WebApplication.targets não foi encontrado, no servidor de compilação. Qual é a sua solução?

Tentar compilar meu projeto no servidor de compilação me dá o seguinte erro:

Microsoft (R) Build Engine Version 4.0.30319.1
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.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.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.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.

Resolvi esse problema há alguns meses, com a instalação do Visual Studio 2010 no Build Server. Mas agora estou configurando um novo servidor do zero e quero saber se existe alguma solução melhor para resolver esse problema.

Para responder ao título da pergunta (mas não à pergunta sobre a saída que você está obtendo):

Copiar a seguinte pasta da sua máquina dev para o servidor de compilação corrige isso se forem apenas aplicativos da web

C: \ Arquivos de programas (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications

Remova x86 de acordo com a quebra de sua compilação. Se você tiver outros tipos de projeto, provavelmente precisará copiar toda a pasta msbuild.

A criação e publicação de WAPs não são suportadas se o VS não estiver instalado. Com isso dito, se você realmente não deseja instalar o VS, precisará copiar todos os arquivos abaixo %ProgramFiles32%\MSBuild\Microsoft\.

Você precisará instalar a Web Deploy Tool também. Eu acho que é isso.

UPD: a partir do VS2017, há uma carga de trabalho nas Ferramentas de Construção que elimina esse problema completamente. Consulte a resposta do @SOReader .

Se você preferir não modificar nada no servidor de compilação e ainda assim desejar que o projeto seja compilado fora do controle de origem, pode ser uma boa ideia colocar os binários necessários sob controle de origem. Você precisará modificar a seção de importações no arquivo do seu projeto para ficar assim:

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

A primeira linha é a importação real do novo local que é relativo ao diretório da solução. A segunda é uma versão desativada ( Condition="false") da linha original que permite ao Visual Studio ainda considerar seu projeto como um Projeto de Aplicativo da Web válido (esse é o truque que o VS 2010 SP1 faz sozinho).

Não se esqueça de copiar a pasta C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplicationspara BuildTargetssob seu controle de origem.

No momento, em 2017, você pode instalar as redists do WebApplication com o MSBuildTools. Vá para esta página que fará o download das Ferramentas do MSBuild 2017 e, durante a instalação, clique Web development build toolspara instalar também esses destinos:

Isso levará à instalação de bibliotecas ausentes C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplicationspor padrão

Você também pode usar o pacote NuGet MSBuild.Microsoft.VisualStudio.Web.targets , referenciando-os em seu (s) projeto (s) do Visual Studio, e depois alterar suas referências como Andriy K sugere.

Com base nesta publicação, você pode simplesmente fazer o download do Pacote Redistribuível do Shell do Microsoft Visual Studio 2010 (integrado) e os destinos estão instalados.

Isso evita a necessidade de instalar o Visual Studio no servidor de compilação.

Eu apenas tentei isso agora e posso verificar se funciona:

Antes:

erro MSB4019: O projeto importado "C: \ Arquivos de Programas (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications \ Microsoft.WebApplication.targets" não foi encontrado. Confirme se o caminho na declaração está correto e se o arquivo existe no disco.

Após a instalação:

[Cria corretamente]

Essa é uma solução muito melhor do que instalar o Visual Studio em um servidor de compilação, obviamente.

O SDK do Windows mais recente, como mencionado acima, além do "Pacote Redistribuível do Shell do Microsoft Visual Studio 2010" para Microsoft.WebApplication.targets e "Microsoft Visual Studio Team System 2008 Edição de Banco de Dados GDR R2" para Microsoft.Data.Schema .SqlTasks.targets deve aliviar a necessidade de instalar o Visual Studio 2010. No entanto, a instalação do VS 2010 talvez seja realmente menos geral para baixar e menos trabalho no final.

Adicione dependência através do NuGet e defina um parâmetro de compilação

Objetivo: nenhuma alteração / instalação é necessária para os agentes de construção

Adotei uma abordagem híbrida da abordagem NuGet de Lloyd aqui , que foi baseada na solução de confirmação de dependências binárias da Andrik.

O motivo é que quero poder adicionar novos agentes de construção sem ter que pré-configurá-los com itens como este.

1. Em uma máquina com o Visual Studio, abra a solução; ignore que o projeto da web falha.
2. No gerenciador de pacotes do NuGet, adicione MSBuild.Microsoft.VisualStudio.Web.targets , como Lloyd mencionou.
3. Isso resolverá os binários para [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
   1. Você pode copiá-los para uma pasta de referências e confirmar,
   2. Ou apenas use-os onde estão. Eu escolhi isso, mas vou ter que lidar com o número da versão no caminho mais tarde.

Na versão 7, fiz o seguinte. Isso pode não ter sido necessário e, com base nos comentários, definitivamente não é necessário agora. Por favor, veja os comentários abaixo.

1. Em seguida, na configuração de construção do TeamCity, adicione um Paramenter de construção env.VSToolsPathe defina-o na pasta VSToolsPath; eu usei..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath

Ao criar no servidor de build / IC, desative a importação Microsoft.WebApplication.targetstotalmente, especificando /p:VSToolsPath=''. Essencialmente, isso tornará a condição da seguinte linha falsa:

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

É assim que é feito no TeamCity:

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

Altere seu valor de 4.0 para 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

Origem da solução

Parece que a nova versão do msbuild não é fornecida com o Microsoft.WebApplication.targets. Para corrigir, você precisa atualizar seu arquivo csproj da seguinte maneira:

1) Edite o aplicativo web csproj (clique com o botão direito do mouse). Localize a seção no csproj na parte inferior referente às ferramentas de construção. Deve parecer assim.

<PropertyGroup>  
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />  

2) Você precisa adicionar uma linha VSToolsPath abaixo da marca VisualStudioVersion para que pareça

<PropertyGroup>  
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <!--Add the below line to fix the project loading in VS 2017 -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  <!--End -->
</PropertyGroup>  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />  

Link de referência: https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/

Isso é tudo que você precisa. Apenas 103MB. Não instale tudo

Eu encontrei isso no MS connect :

Sim, você precisa instalar o Visual Studio 2010 em sua máquina de compilação para criar projetos de banco de dados. Fazer isso não requer uma licença adicional do Visual Studio.

Então, essa é a única opção que tenho por enquanto.

Minha solução é uma mistura de várias respostas aqui.

Eu verifiquei o servidor de compilação e o Windows7 / NET4.0 SDK já estava instalado, então encontrei o caminho:

C: \ Arquivos de programas (x86) \ MSBuild \ Microsoft \ VisualStudio \ v9.0 \ WebApplications \ Microsoft.WebApplication.targets`

No entanto, nesta linha:

<Importar Projeto = "$ (MSBuildExtensionsPath) \ Microsoft \ VisualStudio \ v9.0 \ WebApplications \ Microsoft.WebApplication.targets" />

$ (MSBuildExtensionsPath) se expande para C: \ Arquivos de Programas \ MSBuild, que não possui o caminho.

Portanto, o que eu fiz foi criar um link simbólico, usando este comando:

mklink / J "C: \ Arquivos de programas \ MSBuild \ Microsoft \ VisualStudio" "C: \ Arquivos de programas (x86) \ MSBuild \ Microsoft \ VisualStudio"

Dessa forma, o $ (MSBuildExtensionsPath) se expande para um caminho válido e nenhuma alteração é necessária no próprio aplicativo, apenas no servidor de compilação (talvez seja possível criar o link simbólico a cada compilação, para garantir que essa etapa não seja perdida e "esteja documentada" ").

Corrigi isso adicionando
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"

em
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments

Tentei várias soluções, mas no final esta resposta funcionou para mim: https://stackoverflow.com/a/19826448/431522

Isso basicamente implica chamar o MSBuild a partir do diretório MSBuild, em vez do diretório do Visual Studio.

Também adicionei o diretório MSBuild ao meu caminho, para facilitar a codificação dos scripts.

Alguém vindo aqui para o Visual Studio 2017. Eu tive o problema semelhante e não pude compilar o projeto após a atualização para 15.6.1. Eu tive que instalar as ferramentas do MSBulild, mas o erro ainda estava lá.

Consegui corrigir o problema, copiando a v14.0pasta C:\Program Files (x86)\MSBuild\Microsoft\VisualStudiopara a mesma pasta v15.0e resolvendo todos os erros. Então agora minha estrutura de pastas se parece abaixo, onde ambas as pastas contêm o mesmo conteúdo.

Se você estiver usando o MSBuild, como no caso de um servidor de compilação, o que funcionou para mim é:

Mude o seguinte:

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

para:

<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Meu comando Msbuild é: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*

Espero que isso ajude alguém.

Caso esteja tentando implantar um projeto usando o VSTS, o problema pode estar relacionado à seleção da opção "Hosted Windows Container" em vez de "Hosted VS2017" (ou 18, etc.):

• Após a instalação das ferramentas MSBuild da Microsoft, defina o caminho do MSBuild na variável de ambiente, para que possa ser executado a partir de qualquer caminho.
• Edite o arquivo .csproj em qualquer editor de bloco de notas, como o bloco de notas ++, e comente o
• Verifique os seguintes elementos, ->
  • Certifique-se de usar a importação apenas uma vez, escolha o que funcionar.
  • Verifique se existe a seguinte pasta na unidade, "C: \ Arquivos de Programas (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0" ou qualquer versão referenciada pelo destino do MSBuild em "C: \ Arquivos de Programas (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ WebApplications \ Microsoft.WebApplication.targets "
  • No prompt de comando, execute o seguinte comando, para verificar

C:> msbuild "C: \\ DotnetCi.sln" / p: Configuração = Release / p: UseWPP_CopyWebApplication = true / p: PipelineDependsOnBuild = false

• escolha / p alternar conforme apropriado, consulte a descrição do link aqui e a descrição da imagem aqui

Eu estava com esse problema criando um projeto do SQL Server em um pipeline de CI / CD. Na verdade, eu também estava localmente e não consegui resolvê-lo.

O que funcionou para mim foi usar um MSBuild SDK , capaz de produzir um pacote de aplicativos da camada de dados do SQL Server ( .dacpac) a partir de um conjunto de scripts SQL, o que implica a criação de um novo projeto. Mas eu queria manter o projeto do SQL Server, para poder vinculá-lo ao banco de dados ativo por meio do SQL Server Object Explorer no Visual Studio. Executei as seguintes etapas para instalar e executar:

1. Mantive meu projeto do SQL Server com os .sqlscripts do banco de dados.
2. Criou um projeto de biblioteca de classes do .NET Standard 2.0, certificando-se de que a estrutura de destino fosse o .NET Standard 2.0, conforme as diretrizes no link acima.

3. Defina o conteúdo da .csprojseguinte maneira:

   <?xml version="1.0" encoding="utf-8"?>
   <Project Sdk="MSBuild.Sdk.SqlProj/1.0.0">
     <PropertyGroup>
       <SqlServerVersion>Sql140</SqlServerVersion>
       <TargetFramework>netstandard2.0</TargetFramework>
     </PropertyGroup>
   </Project>

4. Eu escolhi o Sql140 como a versão do SQL Server porque estou usando o SQL Server 2019. Verifique esta resposta para descobrir o mapeamento para a versão que você está usando.

5. Ignore o projeto do SQL Server na compilação, para que ele pare de ser interrompido localmente (ele cria no Visual Studio, mas falha no VS Code).

6. Agora, apenas precisamos garantir que os .sqlarquivos estejam dentro do projeto SDK quando ele for criado. Consegui isso com uma rotina simples de PowerShell no pipeline de CI / CD que copiava os arquivos do projeto SQL Server para o projeto SDK:

Copy-Item -Path "Path.To.The.Database.Project \ dbo \ Tables \ *" -Destination (New-item -Name "dbo \ Tables" -Type Directory -Path "Path.To.The.DatabaseSDK.Project \ ")

PS: Os arquivos precisam estar fisicamente no projeto SDK, na raiz ou em alguma pasta, para que os links para os .sdkarquivos no projeto SQL Server não funcionem. Em teoria, deveria ser possível copiar esses arquivos com uma condição de pré-compilação, mas por algum motivo obscuro, isso não estava funcionando para mim. Tentei também ter os .sqlarquivos no projeto SDK e vinculá-los ao projeto do SQL Server, mas isso quebraria facilmente o vínculo com o SQL Server Object Explorer, então decidi deixar isso também.