winapi .net-4.0 msbuild teamcity

winapi - MSBuild en el servidor CI no puede encontrar AL.exe



.net-4.0 teamcity (7)

Tengo un problema en mi servidor de compilación de TeamCity CI, donde durante la compilación recibo el siguiente error:

C: / WINDOWS / Microsoft.NET / Framework / v4.0.30319 / Microsoft.Common.targets (2342, 9): error MSB3086: La tarea no pudo encontrar "AL.exe" utilizando SdkToolsPath "" o la clave de registro "HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / Microsoft SDKs / Windows / v7.0A ". Asegúrese de que SdkToolsPath esté configurado y de que la herramienta exista en la ubicación específica del procesador correcta en SdkToolsPath y de que esté instalado el SDK de Microsoft Windows.

Encontré informes similares de hace un año cuando las personas se estaban actualizando a .NET 3.5, por ejemplo, esta . En ese caso, la instalación del último SDK resolvió el problema, sin embargo, ya instalé el último SDK (SDK de Microsoft Windows para Windows 7 y .NET Framework 4 ) en mi servidor de compilación. Las herramientas MSBuild están todas allí en el servidor, en una carpeta llamada

C: / WINDOWS / Microsoft.NET / Framework / v4.0.30319

y AL.exe existe en

C: / Archivos de programa / Microsoft SDKs / Windows / v7.1 / Bin / NETFX 4.0 Tools

Sin embargo, la clave de registro mencionada en el mensaje de error no existe. Por lo tanto, parece que hay algún problema con la instalación / configuración de MSBuild. Este error solo ocurre en proyectos que tienen recursos incrustados, que requieren AL.exe.

Aunque la pregunta es bastante antigua, pero aún aparece en la parte superior de los resultados de búsqueda de Google, decidí publicar mi solución también. He atrapado en el mismo problema durante la instalación de TeamCity en Windows Server 2016 y Windows 10 Pro.

He instalado Microsoft Build Tools 2015 y Windows 10 SDK (solo herramientas para .NET 4.6.2) y obtuve el error de la pregunta.

El acertijo que faltaba era establecer la variable de entorno: TargetFrameworkSDKToolsDirectory=C:/Program Files (x86)/Microsoft SDKs/Windows/v10.0A/bin/NETFX 4.6.2 Tools .

Después de establecer la variable de entorno, MSBuild pudo resolver todas las herramientas necesarias, incluidas AL.exe y la creación correcta.

Indíqueme si se puede lograr lo mismo estableciendo valores en el registro, pero las variables de entorno también funcionan muy bien en este caso y no se necesita ninguna instalación de VS.

Como has instalado el último SDK (supongo que es v7.1)

  1. Vaya a "Microsoft Windows SDK v7.1" desde el menú Inicio
  2. Seleccione "Símbolo del sistema de Windows SDK 7.1" e ingrese

  3. Configuración de cd

  4. WindowsSdkVer -version: v7.1

Esto le indicará a msbuild que use esa versión de las herramientas sin necesidad de realizar ninguna edición de registro aterradora.

Recientemente tuvimos este problema tratando de hacer funcionar nuestras compilaciones .Net 4.0. Descubrimos que la ubicación de al.exe había cambiado entre el aspecto del MSBuild original que venía con .Net 4.0 y el SDK de Visual Studio para .Net 4.0 (que se publicó más adelante).

Dado que la única instalación independiente de las herramientas de SDK disponible es la que ya habíamos instalado sin éxito (la que usted mencionó), la única solución que podíamos pensar era instalar Visual Studio en los agentes de compilación. Pusimos Visual Studio 2010 Express (para mantener la instalación lo más ligera posible) allí y el problema desapareció. No es una solución bonita, pero funcionó: la instalación de VS2010 también instala las herramientas de SDK de la versión específica que MSBuild parece estar buscando.

Este es un problema que realmente no debería suceder, pero no parecía haber una forma de hacer que MSBuild se vea en el lugar correcto para las herramientas, incluso pirateando el registro.

También debe aplicar la siguiente corrección de registro para actualizar msbuild para que apunte a los valores sdk de la V7.1.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/MSBuild/ToolsVersions/4.0] "MSBuildToolsPath"="C://WINDOWS//Microsoft.NET//Framework//v4.0.30319//" "MSBuildToolsRoot"="C://WINDOWS//Microsoft.NET//Framework//" "FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE//SOFTWARE//Microsoft//Microsoft SDKs//Windows//v7.1@InstallationFolder)" "MSBuildRuntimeVersion"="4.0.30319" "SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE//SOFTWARE//Microsoft//Microsoft SDKs//Windows//v7.1//WinSDK-NetFx40Tools-x86@InstallationFolder)" "SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE//SOFTWARE//Microsoft//Microsoft SDKs//Windows//v7.1//WinSDKNetFx35Tools@InstallationFolder)" "MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE//SOFTWARE//Microsoft//MSBuild//ToolsVersions//4.0@MSBuildToolsPath)"

Tengo una solución simple y efectiva.

El problema parece ser que la versión de herramientas entregada con Visual Studio es la versión 7.0A, mientras que la versión entregada con el SDK de Windows es la versión 7.1. Eso está muy bien, pero MSBuild.exe todavía está buscando las claves de registro de la versión 7.0A, que no existen. ¡Esto tiene que ser un error!

Buscando en mi registro, toda la información para V6.0 y V7.1 está presente y es correcta. Entonces mi solución es simple. Creé un enlace de registro que crea un alias de las claves 7.1.

No es posible crear enlaces de registro usando las herramientas integradas, así que descargué una pequeña utilidad llamada ''regln'' desde here .

C:> regln-x86.exe "/ Registry / Machine / SOFTWARE / Microsoft / Microsoft SDKs / Windows / v7.0A" "/ Registry / Machine / SOFTWARE / Microsoft / Microsoft SDKs / Windows / v7.1"

Trabajo hecho. MSBuild ahora funciona perfectamente en el servidor de TeamCity.

Tuve el mismo problema allí, aquí está mi respuesta simple a esto.

Después de haber instalado el Microsoft Windows SDK 7.1 en el servidor de TeamCity.

En Regedit Cambiar esta clave

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/MSBuild/ToolsVersions/4.0/SDK40ToolsPath

a

$(Registry:HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Microsoft SDKs/Windows/v7.1/WinSDK-NetFx40Tools-x86@InstallationFolder)