Microsoft.WebApplication.targets no se encontró en el servidor de compilación. Cual es tu solucion

Intentar compilar mi proyecto en el servidor de compilación me da el siguiente error:

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.

Resolví este problema hace unos meses, con la instalación de Visual Studio 2010 en el servidor de compilación. Pero ahora estoy configurando un nuevo servidor desde cero, y quiero saber si hay alguna solución mejor para resolver este problema.

Para responder el título de la pregunta (pero no la pregunta sobre el resultado que está obteniendo):

Copiar la siguiente carpeta desde su máquina de desarrollo a su servidor de compilación corrige esto si solo se trata de aplicaciones web

C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications

Elimina x86 según cómo se rompa tu compilación. Si tiene otros tipos de proyectos, probablemente necesite copiar toda la carpeta msbuild.

La creación y publicación de WAP no es compatible si VS no está instalado. Dicho esto, si realmente no desea instalar VS, deberá copiar todos los archivos que se encuentran debajo %ProgramFiles32%\MSBuild\Microsoft\.

También necesitará instalar la herramienta de implementación web . Creo que eso es todo.

UPD: a partir de VS2017, existe una carga de trabajo en Build Tools que elimina este problema por completo. Ver la respuesta de @SOReader .

Si prefiere no modificar nada en el servidor de compilación, y aún desea que el proyecto se compile directamente fuera del control de origen, puede ser una buena idea poner los binarios necesarios bajo control de origen. Tendrá que modificar la sección de importaciones en su archivo de proyecto para que se vea así:

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

La primera línea es la importación real desde la nueva ubicación que es relativa al directorio de la solución. La segunda es una versión desactivada ( Condition="false") de la línea original que permite que Visual Studio todavía considere que su proyecto es un Proyecto de Aplicación Web válido (ese es el truco que VS 2010 SP1 hace por sí mismo).

No se olvide de copiar el C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplicationsde BuildTargetscarpeta bajo el control de código fuente.

En este momento, en 2017, puede instalar redistas de aplicaciones web con MSBuildTools. Simplemente vaya a esta página que descargará MSBuild 2017 Tools y durante la instalación, haga clic Web development build toolspara instalar también estos objetivos:

Esto conducirá a la instalación de bibliotecas faltantes C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplicationspor defecto

También puede usar el paquete NuGet MSBuild.Microsoft.VisualStudio.Web.targets , haciendo referencia a ellos dentro de su (s) proyecto (s) de Visual Studio, luego cambie sus referencias como sugiere Andriy K.

Con base en esta publicación aquí , simplemente puede descargar el paquete redistribuible de Microsoft Visual Studio 2010 Shell (integrado) y los destinos están instalados.

Esto evita la necesidad de instalar Visual Studio en el servidor de compilación.

Acabo de probar esto ahora y puedo verificar que funciona:

Antes de:

error MSB4019: no se encontró el proyecto importado "C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications \ Microsoft.WebApplication.targets". Confirme que la ruta en la declaración es correcta y que el archivo existe en el disco.

Después de la instalación:

[Construye correctamente]

Obviamente, esta es una solución mucho mejor que instalar Visual Studio en un servidor de compilación.

El último SDK de Windows, como se mencionó anteriormente, además del "Paquete redistribuible (integrado) de Microsoft Visual Studio 2010 Shell" para Microsoft.WebApplication.targets y "Microsoft Visual Studio Team System 2008 Database Edition GDR R2" para Microsoft.Data.Schema .SqlTasks.targets debería aliviar la necesidad de instalar Visual Studio 2010. Sin embargo, la instalación de VS 2010 en realidad puede ser menos general para descargar y menos trabajo al final.

Agregue dependencia a través de NuGet y establezca un parámetro de compilación

Objetivo: no se necesitan cambios / instalaciones para los agentes de compilación

Aquí tomé un enfoque híbrido del enfoque NuGet de Lloyd , que se basó en el solución de dependencias binarias comprometidas de Andrik.

El motivo es que quiero poder agregar nuevos agentes de compilación sin tener que configurarlos previamente con elementos como este.

1. En una máquina con Visual Studio, abra la solución; ignore que el proyecto web falla.
2. En el administrador de paquetes NuGet, agregue MSBuild.Microsoft.VisualStudio.Web.targets , como mencionó Lloyd.
3. Esto resolverá los binarios para [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
   1. Puede copiarlos en una carpeta de referencias y commit,
   2. O simplemente úselos donde están. Elegí esto, pero tendré que lidiar con el número de versión en la ruta más adelante.

En la versión 7, hice lo siguiente. Esto puede no haber sido necesario, y en base a los comentarios definitivamente no es necesario ahora. Por favor, vea los comentarios a continuación.

1. A continuación, en la configuración de compilación de TeamCity, agregue un Paramenter de compilación env.VSToolsPathy configúrelo en la carpeta VSToolsPath; solía..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath

Al compilar en el servidor de compilación / CI, desactive la importación por Microsoft.WebApplication.targetscompleto especificando /p:VSToolsPath=''. Esto, esencialmente, hará que la condición de la siguiente línea sea falsa:

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

Así es como se hace en TeamCity:

Si migra Visual Studio 2012 a 2013, abra el archivo de proyecto * .csproj con edior.
y marque el elemento ToolsVersion de la etiqueta 'Proyecto'.

Cambie su valor de 4.0 a 12.0

• Desde

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

• A

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

O bien, si crea con msbuild, simplemente especifique la propiedad VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0

Fuente de solución

Parece que la nueva versión de msbuild no se incluye con Microsoft.WebApplication.targets. Para solucionarlo, debe actualizar su archivo csproj de la siguiente manera:

1) Edite la aplicación web csproj (clic derecho). Encuentre la sección en csproj hacia la parte inferior sobre herramientas de compilación. Debería verse así.

<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) Debe agregar una línea VSToolsPath debajo de la etiqueta VisualStudioVersion para que se vea así

<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" />  

Enlace de referencia: https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/

Esto es todo lo que necesita. Solo 103MB. No instales todo

He encontrado esto en MS connect :

Sí, debe instalar Visual Studio 2010 en su máquina de compilación para compilar proyectos de bases de datos. Hacerlo no requiere una licencia adicional de Visual Studio.

Entonces, esta es la única opción que tengo por ahora.

Mi solución es una mezcla de varias respuestas aquí.

Verifiqué el servidor de compilación y Windows7 / NET4.0 SDK ya estaba instalado, así que encontré la ruta:

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

Sin embargo, en esta línea:

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

$ (MSBuildExtensionsPath) se expande a C: \ Archivos de programa \ MSBuild que no tiene la ruta.

Por lo tanto, lo que hice fue crear un enlace simbólico, usando este comando:

mklink / J "C: \ Archivos de programa \ MSBuild \ Microsoft \ VisualStudio" "C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio"

De esta manera, $ (MSBuildExtensionsPath) se expande a una ruta válida, y no se necesitan cambios en la aplicación en sí, solo en el servidor de compilación (quizás uno podría crear el enlace simbólico en cada compilación, para asegurarse de que este paso no se pierda y esté "documentado ").

Lo arreglé agregando
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"

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

Probé un montón de soluciones, pero al final esta respuesta funcionó para mí: https://stackoverflow.com/a/19826448/431522

Básicamente implica llamar a MSBuild desde el directorio de MSBuild, en lugar del directorio de Visual Studio.

También agregué el directorio MSBuild a mi ruta, para que los scripts sean más fáciles de codificar.

Alguien que vino aquí para Visual Studio 2017. Tuve el problema similar y no pude compilar el proyecto después de la actualización a 15.6.1. Tuve que instalar las herramientas de MSBulild pero aún así el error estaba allí.

Pude solucionar el problema copiando la v14.0carpeta de C:\Program Files (x86)\MSBuild\Microsoft\VisualStudiola misma carpeta v15.0y eso resolvió todos los errores. Entonces, la estructura de mi carpeta se ve a continuación, donde ambas carpetas contienen el mismo contenido.

Si está utilizando MSBuild, como en el caso de un servidor de compilación, lo que funcionó para mí es:

Cambia lo siguiente:

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

a:

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

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

Espero que esto ayude a alguien.

En caso de que si está tratando de implementar un proyecto usando VSTS, el problema podría estar relacionado con la opción "Contenedor de Windows alojado" en lugar de "VS2017 alojado" (o 18, etc.):

• Después de la instalación de las herramientas de MSBuild de Microsoft, defina la ruta de MSBuild en la variable de entorno, de modo que pueda ejecutarse desde cualquier ruta.
• Edite el archivo .csproj en cualquier editor de bloc de notas, como notepad ++, y comente el
• Verifique los siguientes elementos, ->
  • Asegúrese de utilizar la importación solo una vez, elija lo que funcione.
  • Asegúrese de tener la siguiente carpeta en la unidad, "C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0" o la versión a la que haga referencia el destino de MSBuild en "C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ WebApplications \ Microsoft.WebApplication.targets "
  • Desde el símbolo del sistema, ejecute el siguiente comando para verificar

C:> msbuild "C: \\ DotnetCi.sln" / p: Configuration = Release / p: UseWPP_CopyWebApplication = true / p: PipelineDependsOnBuild = false

• elija el interruptor / p según corresponda, consulte la descripción del enlace aquí ingrese la descripción de la imagen aquí

Estaba teniendo este problema al construir un proyecto de SQL Server en una tubería de CI / CD. De hecho, también lo tenía localmente y no pude resolverlo.

Lo que funcionó para mí fue usar un SDK de MSBuild , capaz de producir un paquete de aplicación de nivel de datos de SQL Server ( .dacpac) a partir de un conjunto de scripts SQL, lo que implica crear un nuevo proyecto. Pero quería mantener el proyecto de SQL Server, para poder vincularlo a la base de datos en vivo a través del Explorador de objetos de SQL Server en Visual Studio. Tomé los siguientes pasos para tener esto en funcionamiento:

1. Mantuve mi proyecto de SQL Server con el .sql scripts de base de datos.
2. Creé un proyecto de biblioteca de clases .NET Standard 2.0, asegurándome de que el marco de destino fuera .NET Standard 2.0, según las pautas en el enlace anterior.

3. Establezca el contenido de la .csprojsiguiente manera:

   <?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. Elegí Sql140 como la versión de SQL Server porque estoy usando SQL Server 2019. Verifique esta respuesta para averiguar la asignación a la versión que está usando.

5. Ignore el proyecto de SQL Server en la compilación, de modo que deje de romperse localmente (se compila en Visual Studio, pero falla en el código VS).

6. Ahora solo tenemos que asegurarnos de que los .sqlarchivos están dentro del proyecto SDK cuando se construye. Lo logré con una rutina simple de PowerShell en la tubería de CI / CD que copiaría los archivos del proyecto SQL Server al proyecto 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 \ ")

PD: los archivos deben estar físicamente en el proyecto SDK, ya sea en la raíz o en alguna carpeta, por lo que los enlaces a los .sdkarchivos en el proyecto SQL Server no funcionarán. En teoría, debería ser posible copiar estos archivos con una condición previa a la compilación, pero por alguna oscura razón, esto no funcionaba para mí. Intenté también tener los .sqlarchivos en el proyecto SDK y vincularlos al proyecto de SQL Server, pero eso rompería fácilmente el enlace con el Explorador de objetos de SQL Server, por lo que decidí eliminar esto también.