msbuild .net-4.5 msbuild-4.0

La implementación de MSBuild falla después de la actualización a.NET 4.5



.net-4.5 msbuild-4.0 (5)

Recientemente hemos actualizado nuestra aplicación VS 2010 y .NET 4 a VS 2012 y .NET 4.5. Tenemos un script de compilación para implementar la aplicación en el servidor de prueba. Tenemos dos cajas: una es Windows 8 con VS 2012 (instalación nueva) y otra es Windows 7 con VS 2010 y VS 2012 (instalada recientemente).

Cuando se ejecuta el script de compilación desde Windows 8 box script de compilación funciona bien y implementa la aplicación para probar el servidor. Pero al implementar la aplicación desde Windows 7, aparece el siguiente error:

"C: / Achinth / Build / Work / build / qa1sb.proj" (DeployAll target) (1) -> "C: / Achinth / Build / Work / App / App.csproj" (ResolveReferences; MsDeployPublish target) (2) -> (MSDeployPublish target) -> C: / Archivos de programa (x86) / MSBuild / Microsoft / VisualStudio / v10.0 / Web / Microsoft.Web.Publishing.targets (3847,5): error: error en la tarea de implementación web. ( (19/8/2012 6:23:41 PM) Se produjo un error cuando la solicitud se procesó en la computadora remota.) [C: / Achinth / Build / Work / App / App.csproj] C: / Archivos de programa (x86 ) / MSBuild / Microsoft / VisualStudio / v10.0 / Web / Microsoft.Web.Publishing.targets (3847,5): error: / r [C: / Achinth / Build / Work / App / App.csproj] C: / Archivos de programa (x86) / MSBuild / Microsoft / VisualStudio / v10.0 / Web / Microsoft.Web.Publishing.targets (3847,5): error: (8/19/2012 6:23:41 PM) Ocurrió un error cuando la solicitud se procesó en la computadora remota. / r [C: / Achinth / Build / Work / App / App.csproj] C: / Archivos de programa (x86) / MSBuild / Microsoft / VisualStudio / v10.0 / Web / Microsoft. Web.Publishing.targets (3847,5): error: el grupo de aplicaciones t Lo que estás intentando usar tiene la propiedad ''managedRuntimeVersion'' establecida en ''v4.0''. Esta aplicación requiere ''v4.5''. [C: / Achinth / Build / Work / App / App.csproj]

Mirando el error, parece que MSBuild está usando objetivos de VS 2010 en lugar de VS 2012, lo que está causando el error. Como Windows 8 box no tiene VS 2010, está usando los objetivos de VS 2012 correctamente.

¿Alguien puede proporcionar sugerencias sobre cómo hacer que MSBuild elija la versión correcta?

En este caso, deberá especificar la propiedad MSBuild VisualStudioVersion = 11.0. Acabo de publicar un blog sobre esto en http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx , lo he pegado a continuación también para su comodidad.

Una de las características más solicitadas de Visual Studio 2012 fue la capacidad de abrir proyectos tanto en VS 2012 como en VS 2010 (requiere VS 2010 SP1). En caso de que no hayas escuchado, implementamos esa característica. Quizás se esté preguntando cómo pudimos hacer esto y cómo esto podría afectarle.

Si abre .csproj / .vbproj para un Proyecto Web creado en VS2010, verá la siguiente declaración de importación.

<Import Project="$(MSBuildExtensionsPath32)/Microsoft/VisualStudio/ v10.0/WebApplications/Microsoft.WebApplication.targets" />

Cuando abre este proyecto en VS 2012, se realizan algunos cambios en el archivo de su proyecto para garantizar que pueda abrirse tanto en VS 2010 SP1 como en VS 2012. Uno de los cambios realizados en el proyecto cuando se carga por primera vez en VS 2012 es agregar lo siguiente para reemplazar esa declaración de importación.

<PropertyGroup> <VisualStudioVersion Condition="''$(VisualStudioVersion)'' == ''''">10.0</VisualStudioVersion> <VSToolsPath Condition="''$(VSToolsPath)'' == ''''"> $(MSBuildExtensionsPath32)/Microsoft/VisualStudio/v$(VisualStudioVersion)</VSToolsPath> </PropertyGroup> <Import Project="$(VSToolsPath)/WebApplications/Microsoft.WebApplication.targets" Condition="''$(VSToolsPath)'' != ''''" />

Eliminamos el código 10.0 y usamos la propiedad VisualStudioVersion. Cuando se construye en Visual Studio 2012, este valor siempre será 11.0, pero para VS 2010 no existe. Es por eso que lo dejamos por defecto a 10.0 arriba. Hay algunos escenarios donde la construcción desde la línea de comando requerirá establecer esta propiedad explícitamente. Antes de llegar, permítanme explicar cómo se establece esta propiedad (en este orden)

  1. Si VisualStudioVersion se define como una variable de entorno / propiedad global de MSBuild, eso se usa.
    • Así es como VS y el indicador de comando del desarrollador VS establecen este valor
  2. Basado en la versión de formato de archivo del archivo .sln (el conjunto de herramientas utilizado es el formato de archivo sln –1)
    • Para simplificar esta declaración, el archivo .sln se compilará especificando VisualStudioVersion al valor de la versión de VS que creó el archivo .sln.
  3. Elegir predeterminado
    • 10.0 si está instalado VS 2010
    • Versión de sub-conjunto de herramientas de versión más alta instalada

Para # 2 cuando esté creando un archivo .sln, el valor de VisualStudioVersion será –1 de la versión de formato que se encuentra en el archivo .sln. Lo importante a tener en cuenta aquí es que si compila un archivo .sln, se compilará con el valor de VisualStudioVersion correspondiente a la versión de VS que creó el archivo .sln. Entonces, si creas un archivo .sln en VS2012 y siempre construyes ese archivo .sln, el valor para VisualStudioVersion será 11.0. En muchos casos, si construyes el archivo .sln eres bueno.

¿Si está creando archivos .csproj / .vbproj sin pasar por un archivo .sln? Si crea un proyecto web desde la línea de comandos (no el indicador del desarrollador), el valor de VisualStudioVersion utilizado será 10.0. Ese es un artefacto de las propiedades que mostré arriba. En este caso, debe pasar esto como una propiedad de MSBuild. Por ejemplo

msbuild.exe MyAwesomeWeb.csproj /p:VisualStudioVersion=11.0

En este caso estoy pasando explícitamente en la propiedad. Esto siempre anulará cualquier otro mecanismo para determinar el valor de VisualStudioVersion. Si está utilizando la tarea MSBuild en un script de compilación, puede especificar la propiedad en el atributo Propiedades o en el atributo Propiedades adicionales. Ver mi blog anterior sobre la diferencia entre Propiedades y Propiedades adicionales.

Si encuentra algún comportamiento extraño al crear / publicar y observa que se están importando los archivos .targets incorrectos, es posible que deba especificar esta propiedad.

Observé que cuando uso la función VS2012 Publish Web Deploy Package, genera un archivo .zip. Dentro de ese archivo zip hay un archivo llamado archive.xml que contiene una etiqueta createApp con el atributo ''managedRuntimeVersion = "v4.0"''. Cuando uso msdeploy.exe para sincronizarlo con una instancia de iis, funciona.

Sin embargo, cuando uso msbuild.exe para crear un archivo .zip del paquete web, contiene un archivo archive.xml que tiene ''managedRuntimeVersion = "v4.5"''. Al intentar implementar este paquete web en IIS utilizando msdeploy.exe, se produce el error ERROR_APPPOOL_VERSION_MISMATCH.

Como explicó Sayed Ibrahim Hashimi aquí, agregar "/p:VisualStudioVersion=11.0" a mi línea de comandos msbuild.exe fuerza efectivamente "managedRuntimeVersion =" v4.0 "''en el archivo archive.xml del paquete web resultante para que resuelva el problema.

Para cualquiera que haya encontrado esta página buscando por qué msdeploy / webdeploy muestra un error similar, encontré que esta es la solución.

Para solucionar el problema, simplemente agregue la propiedad DeployManagedRuntimeVersion en su proyecto VS:

<targetframeworkversion>v4.5</TargetFrameworkVersion></code> <DeployManagedRuntimeVersion>v4.0</DeployManagedRuntimeVersion>

Desde aquí: http://techblog.dorogin.com/2013/11/deploying-45-projects-with-webdeploy.html

desde este enlace .

"Abra su archivo de proyecto web * .csproj o * .vbproj en un editor de texto y agregue la siguiente línea.

<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion>

Agregué la línea justo antes de la línea

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

y se despliega sin error ".

Funciono para mi