none
Hacer build de una solution 3.5 en TFS2010 RRS feed

  • Pregunta

  • Hola muy buenas,

     

    tengo una solución en Visual Studio 2010 con el target framework a 3.5 subida a un TFS2010. El tema es que cuando hago una build me dá una error de que no encuentra el ResGen.exe. Esto lo he solucionado canviando la clave LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFX35Tools-x86\Installation Folder al valor C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin. Después me daba un error de que no encontraba el Tracker.exe. Esto lo he solucionado poniendo como argumento a la tarea de compilación que TrackFileAccess=false. No me gusta mucho la solución pero bueno...

    El tema es que ahora me dá el error:

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (2342): La tarea no encontró "AL.exe" mediante el valor "" de SdkToolsPath ni mediante la clave del Registro "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Asegúrese de establecer SdkToolsPath, de que la herramienta exista en la ubicación específica del procesador correcta debajo de SdkToolsPath y de que esté instalado Microsoft Windows SDK.

    ¿Que tengo que cambiar para que funcione correctamente? He leído que instalando el SDK 7.0A todo esto se soluciona, pero si no tengo mal entendido, este es el SDK que se instala con el Visual Studio  2010 y, en principio, instalar el Visual Studio en la máquina de IC es una mala práctica, no?

    Muchas gracias a todos.

    Saludos,

    Vicenç

     


    http://devnettips.blogspot.com
    lunes, 27 de diciembre de 2010 9:40

Respuestas

  • Hola Vicenç, una pregunta... ¿por qué dices que instalar visual studio en la máquina de IC es una mala práctica? En una máquina de build debe ir todo lo necesario para construir el software, y si entre esas cosas está visual studio, en mi opinión no habría mayor problema en instalarlo (por ejemplo en tu caso te hubieses ahorrado seguramente toda la parametrización de msbuild). De hecho hay veces que no queda más remedio, por ejemplo si estás usando características que sólo están disponibles en determinadas ediciones de visual studio. Y además, al instalar VS en la máquina de build no se consume licencia, se puede hacer con la de uno de los desarrolladores.

    Un saludo!!!

     

     

     

    • Marcado como respuesta Vicenç García lunes, 27 de diciembre de 2010 15:05
    lunes, 27 de diciembre de 2010 13:07

Todas las respuestas

  • Hmm ese error concreto no lo he visto, pero la mayor parte de errores en Team Build con temas del registro, se debe a que lo tienes instalado en x64 y la mayor parte de los SDK están en x86, con lo que no "encuentra" las claves bien en el registro.

    Prueba a, en la configuración de la tEam Build, en la parte de proceso, en la sección "advanced", poner que MsBuild se ejecute como x86.


    Luis Fraile - MCSD.NET - MVP Team System - http://www.lfraile.net/
    lunes, 27 de diciembre de 2010 10:57
  • Ya lo he probado y dá el mismo error.

     

    Lo que no entiendo es que de las claves del registro que se queja, en la ruta que apuntan si que está el archivo AL.exe... Y lo otro que no entiendo es que dice que el valor de SdkToolsPath vale "", cuando yo se lo especifico como parámetro en el msbuild:

     

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /nologo /noconsolelogger "C:\Windows\TEMP\UI\XXXX\XXXX Main Line\2\Sources\Client\XXXX.sln" /m:1 /fl /flp:"logfile=C:\Windows\TEMP\UI\XXXX\XXXX Main Line\2\Sources\Client\XXXX.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /p:TrackFileAccess=false /p:SdkToolsPath="C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin" /p:OutDir="C:\Windows\TEMP\UI\Indra CCTV Suite\XXXX Main Line\2\Binaries\\" /p:VCBuildOverride="C:\Windows\TEMP\UI\XXXX\XXXX Main Line\2\Sources\Client\XXXX.sln.vsprops"  /dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/29;InformationNodeId=7016;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;TFSUrl=http://localhost:8080/tfs/DefaultCollection;"*WorkflowForwardingLogger,"C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;"


    http://devnettips.blogspot.com
    lunes, 27 de diciembre de 2010 11:23
  • Muy buenas,

     

    ya tengo la compilación funcionando. Lo que he hecho es poner en los parámetros del msbuild la siguiente línea:

    /p:TrackFileAccess=false /p:SdkToolsPath="C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin" /p:AlToolPath="C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin" /p:LcToolPath="C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin"

     

    No me parece la solución más elegante del mundo, pero por lo menos funciona. Ahora tengo problemas con los eventos de post-build y donde copia el TeamBuild los assemblies, pero si de caso ya lo hago en otro hilo.

     

    Muchas gracias!!


    http://devnettips.blogspot.com
    lunes, 27 de diciembre de 2010 12:54
  • Hola Vicenç, una pregunta... ¿por qué dices que instalar visual studio en la máquina de IC es una mala práctica? En una máquina de build debe ir todo lo necesario para construir el software, y si entre esas cosas está visual studio, en mi opinión no habría mayor problema en instalarlo (por ejemplo en tu caso te hubieses ahorrado seguramente toda la parametrización de msbuild). De hecho hay veces que no queda más remedio, por ejemplo si estás usando características que sólo están disponibles en determinadas ediciones de visual studio. Y además, al instalar VS en la máquina de build no se consume licencia, se puede hacer con la de uno de los desarrolladores.

    Un saludo!!!

     

     

     

    • Marcado como respuesta Vicenç García lunes, 27 de diciembre de 2010 15:05
    lunes, 27 de diciembre de 2010 13:07
  • Hola Jose Luís!

    Pués ahora que lo pienso tienes razón. Otra cosa seria en máquina de deploy, pero en máquina de IC no tiene pq...

     

    Ahora mismo lo instalo y os cuento.

     

    Muchas gracias a los dos!


    http://devnettips.blogspot.com
    lunes, 27 de diciembre de 2010 15:05