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.
Respuestas:
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
.fuente
$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)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.1
contargets.x.x.x.x
la versión actual.fuente
Una solución simple a este problema:
Vaya a la siguiente ruta:
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
WebApplications
carpeta de cualquiera de los directorios de la última versión y péguela en otro.Tus problemas deberían resolverse.
fuente
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.
fuente
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.
fuente
# Visual Studio 2010
la primera línea terminó con,Format Version 12.00
ya 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 CITuve 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,
fuente
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*.*
fuente
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:
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í?
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
fuente
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.
fuente
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"/>
fuente
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
fuente