The imported project “C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets” was not found

Dicho archivo .targets corresponde a un set de elementos, propiedades, targets y tareas de escenarios comunies segun se puede ver en la referencia de MSBuild. Estos archivos se instalan con el Visual Studio y/o MSBuild, sin embargo el correspondiente a WebApplication no está incluido.

Buscando si alguien más ha tenido este problema encontré esta nota “TFS 2010 – Solving The Imported Project Microsoft.WebApplication.targets Was Not Found Error”

En dicha nota sugieren literalmente copiar el directorio “C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications” de una máquina de desarrollo al build server, acción que que la compilación suceda.

Al volver a ejecutar el build script comencé a obtener varios warnings indicando lo siguiente:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(847,9): warning MSB3644: The reference assemblies for framework “.NETFramework,Version=v4.0″ were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Donde lo que procede es la instalación del SDK para la .NET Framework 4. Ojo, la Framework 4 se encontraba ya instalada en el servidor de integración, mas no el SDK, así que las referencias que utilizamos en nuestra aplicación, según lo indicaban los warnings,  se resolvían con el GAC, sin embargo, nuestro build no está completamente lipio. Una vez realizadas estas acciones tenemos ya nuestro “Build Success!”

Podemos descargarlo directamente de GitHub y para instalarlo tenemos 2 formas:

Importar el módulo en PowerShell e invocarlo directamente

Esto lo realizamos con las lineas:

Import-Module .\psake.psm1
Invoke-psake .\default.ps1

Debemos estar seguro que la execution policy nos permitirá ejecutar el módulo para ello podemos utilizar el comando de PowerShell

get-executionpolicy

y en caso necesitemos modificarlo, la sugerencia es establecer la policy “remotesigned”

set-executionpolicy remotesigned

Ejecutar el script de PowerShel psake.ps1

# call the psake.ps1 file directly
.\psake.ps1 .\default.ps1

Ejemplo de un script de psake

Algunos puntos clave

• Todo comienza con la task de nombre “Default”
• Es sugerible trabajar siempre con paths absolutos y para ello podemos apoyarnos en los comandos de PowerShell, por ejemplo: Split-Path en la función “Properties” que podemos observar en la documentacion de la estructura de un script psake
• Tenemos a disposición la gama de comandos de PowerShell y por ende la capacidad de extender nuestros build scripts, acá algunos links de referencia:
  • Starting Windows PowerShell
  • Using Windows PowerShell