v11.0 \ WebApplications \ Microsoft.WebApplication.targets no se encontró cuando el archivo realmente hace referencia a v10

84

Primero algunos antecedentes. A finales de 2012, migramos nuestra solución vs2008 a vs2010, pero seguimos apuntando a .NET 3.5. (¡No sé nada más que lo último y lo mejor aquí!)

No habíamos tenido ningún problema con esta configuración hasta hace unas semanas cuando las personas comenzaron a recibir estos errores:

"foo.csproj" (Rebuild target) (16:5) ->
  C:\...\foo.csproj(142,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 declaration is correct, and that the file exists on disk.

Lo interesante es que si miras el archivo del proyecto, hace referencia a v10, lo cual tiene sentido porque no usamos Visual Studio 2012.

Este error nos golpeó a varios de nosotros a la vez e incluso en ramas de código más antiguas que no han cambiado en meses.

Sospecho que se introdujo alguna actualización en nuestras máquinas que confundió las cosas, pero no sé qué hacer al respecto.

La solución a corto plazo ha sido instalar VS 2012 y no usarlo, pero espero algo un poco más limpio que eso.

drs9222
fuente
17
Descubrí que agregar "/p:VisualStudioVersion=10.0" a la línea de comandos de MSBuild hace que esto desaparezca, pero todavía se siente como un truco.
drs9222

Respuestas:

116

Me encontré con el mismo problema con Visual Studio 2013. Resulta que estaba usando la versión anterior de MSBuild, la que viene con .NET Framework, desde la línea de comandos. Microsoft lanza ahora MSBuild como parte del propio Visual Studio y también como un instalador independiente ( http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of- visual-studio.aspx ).

La solución fue utilizar la nueva versión de MSBuild.exe ubicada en C:\Program Files (x86)\MSBuild\12.0\Bin. Una vez que hice eso, todos los errores de objetivos desaparecieron.

EDITAR 1

Como se menciona en los comentarios, cada nueva versión de MSBuild trae consigo un nuevo directorio. Para Visual Studio 2015, use C:\Program Files (x86)\MSBuild\14.0\Bin.

EDITAR 2

Como se menciona en los comentarios, para Visual Studio 2017, use C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.

NathanAldenSr
fuente
1
Publiqué una solicitud en el foro de TeamCity para incorporar la nueva ruta (como se maneja la configuración de NuGet). Ojalá lo solucionen rápidamente.
David Peden
1
El enlace directo en la publicación del blog a la descarga de herramientas por separado ya no es válido. El enlace correcto es: microsoft.com/en-us/download/details.aspx?id=40760 .
David Peden
1
Y así, Jetbrains viene al rescate con la versión 8.0.5. Publicación
David Peden
1
Si tiene scripts de compilación de Powershell locales, simplemente puede agregar a su ruta: $env:Path = $env:Path + ";C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications"y usar v4 msbuild (también puede hacer esto en su cuadro de compilación)
Chris S
4
¡Si! Gracias, esta es la solución adecuada.
Josh M.
52

Si tiene un servidor de compilación que no tiene VS2012 instalado, puede solucionar este problema

a) instalar el paquete MSBuild.Microsoft.VisualStudio.Web.targets en su solución, y

b) reemplazando esta línea en el archivo .csproj:

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

Con esta línea apuntando al paquete nuget

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />

EDITAR

Como @joedragons señala, la versión en la línea actualizada debe coincidir con la versión del paquete nuget, es decir, reemplazar targets.11.0.2.1con targets.x.x.x.xla versión actual.

Daniel de Zwaan
fuente
1
Asimismo, ¡un gran consejo!
Kevin Obee
2
Gracias, gran solución
Pavel
1
Tal vez sea obvio, pero la línea con la que reemplaza debe contener la versión del paquete que instala. El que instalé fue 12.0.4, así que cuando puse la importación de reemplazo, obtuve el mismo error. Cuando cambié a ... Web.targets.12.0.4 \ ... todo bien =) ¡Muchas gracias!
joedragons
2
Ya no necesita la parte b de esta respuesta. Por alguna razón, SO ha rechazado mi edición para eliminar los detalles innecesarios.
bbodenmiller
1
gracias Hice lo mismo con la última versión MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3
Ahmed Samir
23

Una solución simple a este problema:

Vaya a la siguiente ruta:

C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio

Verá la última versión V10.0, v11.0, v12.0 según su instalación de Visual Studio 2010, 2012 o 2013.

Copie la WebApplicationscarpeta de cualquiera de los directorios de la última versión y péguela en otro.

Tus problemas deberían resolverse.

samdubey
fuente
1
Esta OMI es la mejor y más simple solución :)
gideon
Por supuesto, requiere que tenga acceso para hacer esto en el servidor de compilación.
Dave
1
... pero ¿por qué tenemos que hacer esto manualmente? Gracias ... esto me lo arregló en VS21017 (para mí fue una instalación nueva solo con VS2017; ahora creo que fue porque todavía no instalé IIS)
Piotr Kula
Funciona también al copiar a V14.0.
Uwe Keim
12

Descubrí que al instalar Visual Studio 2012 Shell (aislado) gratuito, se instalan los archivos WebApplications v11 MSBuild. Más ligero que una instalación completa de Visual Studio 2012 y sin problemas de licencias.

Thomas F. Abraham
fuente
8

Guau. Acabamos de ver que sucedió lo mismo en nuestra máquina de construcción. Usamos VS2010 y apuntamos a .NET 4.0. Nuestros archivos de proyecto importan explícitamente la versión v10.0 de estos destinos. Sin cambios en el código, ayer la compilación estuvo bien y hoy está fallando con una queja sobre una versión v11.0 faltante. .NET Framework 4.5.1 se instaló / actualizó anoche en esta máquina de compilación como una actualización automática. Vamos a forzar v10.0 con el parámetro (o variable env.), Pero esto ciertamente nos tomó por sorpresa ...

ACTUALIZACIÓN: Lo que es aún más extraño, es que parece ser el caso de que la versión de hoy de msbuild parece estar usando la primera línea del archivo sln para determinar qué VisualStudioVersion usar por defecto, mientras que la versión de ayer no lo hizo:

Format Version 12.00

Probamos cambiando esto manualmente a 11.00 y la compilación comenzó a funcionar nuevamente.

En nuestro caso, aunque estamos apuntando y construyendo todo para 2010 / 4.0, algunos desarrolladores se han estado preparando para VS2012 (desde que MS afirmó que los archivos del proyecto son compatibles), y esta solución en particular se guardó por última vez (hace meses) en VS2012. Antes de hoy, eso no estaba causando ningún problema.

menos código
fuente
1
Esto me ayudó mucho más que la respuesta más votada, que parece tratarse de una situación completamente diferente.
LambdaCruiser
Lo mismo aquí @LambdaCruiser esta respuesta ayudó mucho. Miré el historial de mi archivo .sln y, aunque la segunda línea leyó, # Visual Studio 2010la primera línea terminó con, Format Version 12.00ya que en algún momento había actualizado a vs2012 pero cambiaba de un lado a otro a vs2010. Al igual que Wayne, este problema ocurrió después de ejecutar la actualización de Windows en el servidor CI
wal
6

Tuve el mismo problema. Se corrigió siguiendo las soluciones enumeradas anteriormente. El problema se debe a que la versión adecuada de Visual Studio Tools (BuildTools) no está disponible en el servidor de compilación. Como se señaló anteriormente, esto se puede resolver instalando BuildTools, pero no es la opción en mi caso.

Aquí hay otra alternativa: use Nuget

Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3

Identifique el proyecto de inicio e instale web.targets según la versión de Visual Studio que se esté utilizando. Se modificarán los siguientes archivos que incluyen los cambios necesarios

En packages.config:

<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />

En .csproj:

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />

¡¡¡Espero que esto ayude!!! Buena suerte,

Salud,

usuario2964808
fuente
1
Respuesta perfecta: elimina la necesidad de manipular el archivo csproj o copiar cosas en el servidor de compilación. Trabajó en múltiples versiones de Visual Studio y MSBuild 2017. Sin embargo, eliminé la línea "WebApplication.targets" manualmente; nuget no la eliminó automáticamente.
Gedas Kutka
3

Hack, pero lo resolvió copiando: c: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications *. * A c: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \Aplicaciones web*.*

Wolf5
fuente
1

Recibí este error a fines de noviembre sin realizar ningún cambio en la configuración de mi instalación de TeamCity o en la instalación de MSBuild o en el código fuente. En mi servidor de compilación, Visual Studio ni siquiera está instalado, y el cambio de VS2010 a VS2012 se realizó a fines de agosto sin ningún problema en ese momento.

Mi versión de MSBuild es 4.0.30319.18408, mi servidor de compilación es un Windows Server 2008 R2 SP1 con TeamCity v6.5.3.

Resolví el problema simplemente copiando la carpeta v11 de otro servidor de compilación que no se vio afectado.

Supongo que esto podría haber sucedido de dos maneras:

  1. Se actualizó algo que provocó la eliminación de la carpeta v11. ¿Podría ser una actualización de Windows a .NET o algo así?

  2. Se actualizó algo que cambió mi configuración de TeamCity / MSBuild de usar v10 a v11 y las compilaciones dejaron de funcionar porque la v11 nunca existió.

Tengo una actualización de .NET Framework 4.5.1 el 3 de diciembre, ¿podría ser esa la razón?

Brgds

Jonas

Jonas
fuente
0

Recientemente me he quedado atascado con el mismo problema. Y mi conclusión es que cada versión de VS (v10, v11, v12) cambia la ruta de la variable de compilación, como MSBuildBinPath.

Por lo tanto, especificar la versión exacta de VS no es un truco, porque es posible que ni siquiera tenga instalada la versión adecuada de los archivos. Entonces, será mejor que especifique un parámetro y use los objetivos que existen en su máquina.

En algunos casos excepcionales, es posible que deba instalar una versión específica del paquete VS y Web Deploy. En mi caso, solo la versión fue suficiente para resolver el problema.

Johnny_D
fuente
0

Puede agregar la propiedad VisualStudioVersion de esta manera:

<ItemGroup>
  <ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
    <Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
  </ProjectToBuild>
</ItemGroup>
<MSBuild Projects="@(ProjectToBuild)" Targets="Rebuild"/>
user3586919
fuente
0

Mientras buscaba cómo resolver esto, casi todos recomendaron copiar la carpeta MSBUILD que faltaba o instalar algún SDK de alguna versión.

Afortunadamente, encontré esta publicación increíblemente útil de Donovan Brown: http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!

En pocas palabras, la idea es configurar la versión de VisualStudio que su compilación debe usar en su Definición de compilación:

Haga clic derecho -> "Editar definición de compilación ..."

Vaya a "Procss" -> "3. Avanzado"

y establezca "Argumentos de MSBuild" con

/p:VisualStudioVersion=12.0
A. Yosupov
fuente
No se puede encontrar "Editar definición de compilación ..." en VS2019
Laser42