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

Primero algunos antecedentes. Al final 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 mejor aquí!)

No habíamos tenido ningún problema con esta configuración hasta hace unas semanas cuando la gente comenzó 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 nos fijamos en el archivo de proyecto, hace referencia a v10, que tiene sentido porque no usamos Visual Studio 2012.

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

Sospecho que se introdujeron algunas actualizaciones en nuestras máquinas que confundieron 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.

Me encontré con el mismo problema con Visual Studio 2013. Resultó que estaba usando la versión anterior de MSBuild, la que se envía con .NET Framework, desde la línea de comandos. Microsoft ahora está lanzando MSBuild como parte de Visual Studio y también como un instalador separado ( 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 destino desaparecieron.

EDIT 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 .

EDIT 2

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

Si tiene un servidor de comstackción que no tiene VS2012 instalado, puede solucionarlo

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

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

  

Con esta línea apuntando al paquete nuget

  

EDITAR

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

Una solución simple a este problema:

Ve a la siguiente ruta:

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

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

Copie la carpeta WebApplications desde el directorio de la última versión y péguela a otra.

Tus problemas deben ser resueltos.

Descubrí que al instalar el 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 licencia.

Guau. Acabamos de ver que sucede lo mismo en nuestra máquina de construcción. Usamos VS2010 y target .NET 4.0. Nuestros archivos de proyecto importan explícitamente la versión v10.0 de estos objectives. Sin cambios en el código, ayer la comstackción estaba bien y hoy está fallando con una queja sobre la versión v11.0 que falta. El .NET Framework 4.5.1 se instaló / actualizó anoche en esta máquina de comstackción como una actualización automática. Vamos a forzar v10.0 con el parámetro (o env. Variable), 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 actual de msbuild parece estar utilizando la primera línea del archivo sln para determinar qué VisualStudioVersion usar por defecto, mientras que la versión de ayer no:

 Format Version 12.00 

Probamos manualmente cambiando esto a 11.00 y la comstackció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 (ya 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 un problema.

Tuve el mismo problema. Se corrigió pasando por las soluciones mencionadas anteriormente. El problema se debe a que la versión adecuada de Visual Studio Tools (BuildTools) no está disponible en el servidor de comstackción. Tal 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 los destinos web según la versión de Visual Studio que se esté utilizando. Se modificarán los siguientes archivos que incluyen los cambios requeridos

En packages.config:

  

En .csproj:

  

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

Aclamaciones,

Pavana

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

Recibí este error a fines de noviembre sin realizar ningún cambio ni en la configuración de mi instalación de TeamCity ni en la instalación de MSBuild ni en el código fuente. En mi servidor de comstackció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 comstackción es Windows Server 2008 R2 SP1 con TeamCity v6.5.3.

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

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

  1. Se actualizó algo que desencadenó una 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 comstackciones dejaron de funcionar ya que el 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

Recientemente me he quedado 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 comstackción, como MSBuildBinPath .

Por lo tanto, especificar la versión exacta de VS no es un hack, porque es posible que ni siquiera tenga instalada la versión adecuada de los archivos. Por lo tanto, es mejor que especifique un parámetro y use los objectives 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.

Puede agregar la propiedad VisualStudioVersion de esta manera:

   Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0    

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

Afortunadamente, he encontrado esta publicación tremendamente ú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 comstackción debería usar en su Definición de comstackción:

Haga clic derecho -> “Editar definición de comstackción …”

Vaya a “Procss” -> “3. Avanzado”

y establece “MSBuild Arguments” con

 /p:VisualStudioVersion=12.0