La ejecución de MSBuild no puede leer SDKToolsPath

Hola, estoy teniendo un problema al ejecutar un script NAnt que solía construir correctamente mi sitio web basado en .Net 2.0, al comstackr con VS2008 y sus herramientas asociadas. Recientemente actualicé todos los archivos de proyecto / solución a VS2010, y ahora mi comstackción falla con el siguiente error:

[exec] C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9): error MSB3086: La tarea no pudo encontrar “sgen.exe” utilizando S dkToolsPath “” o el registro clave “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.

Ahora, SÍ tengo versiones anteriores (.Net 3.5) del SDK de Windows instalado en el servidor de comstackción, y el marco completo de .NET 4.0 está instalado, pero no me he encontrado con una versión específica de .NET 4.0 del SDK de Windows.

Después de un poco de experimentación e investigación, finalmente configuré una nueva variable ambiental “SDKToolsPath” y la apunté a la copia de sgen.exe en mi carpeta windows 6.0 sdk. Esto generó el mismo error, pero me hizo notar que, aunque la variable de entorno SDKToolsPath está establecida (confirmó que puedo “hacer eco” en la línea de comando y tiene el valor esperado), el mensaje de error parece indicar que es no se lee (tenga en cuenta las citas vacías).

La mayor parte de la información que he encontrado es .Net 3.5 (o anterior) específico. No hay muchos 4.0 relacionados por ahí todavía. La búsqueda del código de error MSB3086 tampoco generó nada útil. ¿Alguna idea de lo que podría ser esto?

Scott

Tuve que morder la bala e instalar VS 2010 en nuestro servidor de comstackción para solucionar este problema. Por lo que puedo ver, no hay una versión 7.0A del SDK de Windows disponible en ninguna parte de MSDN. Sin embargo, la instalación de VS 2010 parece instalarlo, creando una regkey 7.0A y una carpeta 7.0A en Program Files \ Microsoft SDKs \ Windows.

No podría enfrentar poner Visual Studio en el servidor de comstackción.

El SDK v7.0A es el SDK instalado con Visual Studio 2010 (La A indica que se trata de una versión VS). Desde entonces, se ha lanzado una versión más nueva. Microsoft Windows SDK para Windows 7 y .NET Framework AKA v7.1 .

Lo he instalado en mi servidor de comstackción. Y luego, a través del símbolo del sistema de Windows SDK 7.1 (Inicio => Todos los progtwigs => Microsoft Windows SDK 7.1), configuré la versión predeterminada del SDK como 7.1.

Pasos:

cd Setup WindowsSdkVer.exe -version:v7.1 

Editar para incluir el comentario de LordHits: no es necesario instalar todo el SDK. Instalar solo las opciones “.NET Development / Intellisense and Reference Assemblies” y “.NET Development / Tools” es suficiente.

Simplemente pase el parámetro GenerateSerializationAssemblies con el valor Off a su MsBuild.

 msbuild.exe /p:GenerateSerializationAssemblies=Off 

Me encontré con un problema similar recientemente en nuestro servidor de comstackción.

Copié la carpeta 7.0A (C: \ Archivos de progtwig \ Microsoft SDKs \ Windows \ 7.0A) de mi computadora (que tiene VS2010 instalado) en ella al servidor de comstackción en la misma ubicación.

Después de crear la siguiente clave de registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A. Establezca InstallationFolder en C: \ Program Files \ Microsoft SDKs \ Windows \ 7.0A.

También puede hacer referencia al registro en su máquina con VS2010 ya instalado en él si no está seguro de qué hacer con el registro en el servidor de comstackción.

Me encontré con el mismo error pero en una situación diferente: usar VS 2010 Express e intentar usar la respuesta de Simmo para establecer explícitamente la versión del SDK; sin embargo, WindowsSdkVer.exe (herramienta de configuración de versión) parece no apuntar Express (comprensible ya que es limitada )

Estoy usando VS 2010 Express en Win 7 Prof. y siempre quiero usar v7.0A del Win SDK (que no tiene todas las extensiones necesarias), y no importa qué versión establezca explícitamente como actual WindowsSdkVer.exe (sigue informando que estableció la versión actual del SDK pero para VS 2008, aunque solo tengo 2010 Ex instalado).

Así que mi solución alternativa fue instalar v7.0 WIN SDK (u otra versión como v7.1) y luego renombrar su carpeta de sistema de archivos a v7.0A . Básicamente, le mentí a VS 2010 Express, pero ahora funciona.

Paso manualmente las variables a MSBuild en el servidor de comstackción.

msbuild.exe MyProject.csproj "/p:TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools" "/p:AspnetMergePath=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools"

Sospecho que el archivo de objectives está anulando la ruta de acceso a las herramientas, eché un vistazo rápido a este archivo y establece SDKToolsPath en $ TargetFrameworkSDKToolsDirectory bajo algunos de los objectives allí. No creo que debas configurarlos en el entorno de todos modos, pero pueden necesitar ser arreglados en tus archivos de proyecto.

Tenga en cuenta que de acuerdo con esta página http://nant.sourceforge.net/ Nant no es compatible con .Net 4.0, ¿podría ser este el verdadero problema?

Lo siento, sé que esto realmente no responde a tu pregunta 🙁

Uno de sus proyectos usa sgen.exe (generador de servidor) para generar un servicio web. necesita instalar SDK en Build Server o eliminar las referencias del servicio web del proyecto.

¿Realmente no tienes SDK versión 7.0A instalada? Ese es un problema que deberás corregir. Mire en los archivos de registro de instalación de VS2010 para ver qué salió mal. El SDK debe estar presente en c: \ program files \ microsoft sdks \ windows \ 7.0a y la clave de registro enumerada debe estar presente también. Correr con la versión 6.0a de sgen.exe no está bien, está obligado a usar el comstackdor incorrecto.

Establezca Sdk40ToolsPath lugar de SdkToolsPath para especificar una ubicación que no sea el directorio de instalación.

Me encontré con un problema similar con AL.exe porque acababa de xcopied las herramientas en la máquina de comstackción en lugar de instalar el SDK, por lo que las claves de registro habituales faltaban. Ejecuté una comstackción con salida de diagnóstico (/ verbosity: diagnostic) y noté que había varias rutas de herramientas de SDK definidas: Sdk40ToolsPath, Sdk35ToolsPath y SdkToolsPath. Configurar Sdk40ToolsPath para que apunte a la carpeta de bin de la versión del SDK apropiada me solucionó el problema.

Tuve el mismo problema en una nueva máquina con Windows 10. Mi configuración:

  • Windows 10
  • Visual Studio 2015 instalado
  • SDK de Windows 10

Pero no pude construir proyectos .NET 4.0:

Die Aufgabe konnte “AL.exe” con dem SdkToolsPath-Wert “” oder dem Registrierungsschlüssel “HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

Solución: Después de intentar (y fallar) instalar el SDK de Windows 7 (porque también incluye el SDK de .NET 4.0) necesitaba instalar el SDK de Windows 8 y asegurarme de que esté instalado el “.NET Framework 4.5 SDK”.

Es loco … pero funcionó.

Estoy de acuerdo con la respuesta de IanS. No es necesario instalar un nuevo SDK. Solo asegúrese de que los valores de las claves de registro SDK35ToolsPath y SDK40ToolPath para MSBuild apuntan a valores correctos de clave de registro.

En mi caso, mi proyecto estaba dirigido a .NET 3.5 y tuve que configurar SDK35ToolsPath para la clave HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 a $ (Registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v6.0A \ WinSDKNetFxTools @ InstallationFolder). Y todo funcionó.

Tenemos una PC WinXP y utilizamos Visual Build Pro 6 para construir nuestro software. como algunos de nuestros desarrolladores usan VS 2010, los archivos del proyecto ahora contienen referencias a la “versión 4.0 de la herramienta” y por lo que puedo decir, esto le dice a Visual Build que necesita encontrar un sdk7.x en alguna parte, aunque solo comstackmos para .NET 3.5 . Esto causó que no encuentre lc.exe. Traté de engañarlo apuntando todas las macros al SDK 6.0A que venía con VS2008 que está instalado en la PC, pero eso no funcionó.

Finalmente lo conseguí trabajando descargando e instalando sdk 7.1. Luego creé una clave de registro para 7.0A y señalé la ruta de instalación a la ruta de instalación de 7.1 sdk. ahora encuentra felizmente un “lc.exe” compatible y todo el código comstack bien. Tengo la sensación de que ahora también podré comstackr el código .NET 4.0 aunque VS2010 no esté instalado, pero aún no lo he intentado.

ToolsVersion = “4.0” lo hace por mí en mi proyecto MSBuild:

  

Tuve el mismo problema e instalé Windows SDK 7.0 y Windows SDK 7.1, que no solucionaron el problema. La causa del problema para mí fue que la biblioteca de clase ofensiva se creó con Target Framework of .NET Framework 2.0.

Lo cambié a .NET Framework 4.0 y trabajé localmente y cuando me registré, el servidor de comstackción lo construyó con éxito.

Tuve un problema similar, en particular, el msbuild falla: MSB3086, MSB3091: “AL.exe”, “resgen.exe” no encontrado

En una máquina con Windows 7 de 64 bits, instalé .Net framework 4.5.1 y Windows SDK para Windows 8.1.

Aunque las configuraciones para el SDK dicen que estaba actualizado, probablemente no fue así. Resolví el problema al eliminar todas las versiones instaladas de SDK, luego instalé lo siguiente, en este orden:

http://www.microsoft.com/en-us/download/details.aspx?id=3138

http://www.microsoft.com/en-us/download/details.aspx?id=8279

http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx

http://msdn.microsoft.com/en-us/windows/desktop/aa904949.aspx

Respuesta corta: en el archivo .csproj, hay una forma de especificar la ruta a sgen.exe, usando SGenToolPath:

   C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools  

Tu camino puede ser diferente, pero SGenToolPath es lo que quieres.

Para obtener una lista de otras propiedades comunes de MSBuild Project, consulte: https://msdn.microsoft.com/en-us/library/bb629394.aspx

Terminamos usando esta configuración de SGenToolPath en el archivo .csproj, en lugar de editar los valores del registro en el servidor de comstackción. Editar los valores de registro en mi máquina local también funcionó, pero era un poco más complicado y no queríamos meternos con el registro en el servidor de comstackción.

Para el registro: en ese caso, el problema era que SDK40ToolsPath (s) en HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild apuntaban a un valor de registro $ (Registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86 @ InstallationFolder) que no existía. Acabo de reemplazar eso con la ruta real directamente.

Primero asegúrese de que ya esté descargando dotNetFx40_Full_x86_x64.exe e instalado (comúnmente se vincula con Visual Stdio).

A continuación, establezca rápidamente nuevas variables de entorno en las variables del sistema. como a continuación: "TargetFrameworkSDKToolsDirectory":"C:\Program Files (x86)\Microsoft SDKs\Windows\vxx.0A\bin\NETFX 4.6.1 Tools" //note:the path:'\vxx.0A\' is a variable indicating your version. it's '\v10.0A\' for me. "TargetFrameworkSDKToolsDirectory":"C:\Program Files (x86)\Microsoft SDKs\Windows\vxx.0A\bin\NETFX 4.6.1 Tools" //note:the path:'\vxx.0A\' is a variable indicating your version. it's '\v10.0A\' for me.

Además de las modificaciones de registro, es posible que necesite cambiar la versión de .net sdk que su configuración estableció en Visual Studio.

Estaba teniendo este problema y decidí verificar la configuración de depuración del proyecto.

Proyecto => Propiedades de la barra de herramientas => Botón de depurar opciones avanzadas de comstackción

Target Framework (todas las configuraciones) se configuró en 3.0, que no está en mi sistema.

Cambié eso a 4.0, luego tuve que reiniciar el proyecto y Visual Studio 2010.

El proyecto luego se construyó sin errores y se ejecutó.

Tuve un problema similar. Hice un proyecto usando Visual Studio 2010 y luego obtuve el error anterior cuando lo compilé usando Visual Studio 2012 . Simplemente copié todo el contenido de C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A en C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A y eso resolvió mi problema.

Acabo de tener este error con un archivo .sln que se creó originalmente en Visual Studio 2010 (y está siendo desarrollado por Visual Studio 2010 y TFS 2010). Había modificado el archivo de la solución para NO crear un proyecto que no se suponía que fuera construido en una configuración particular y Visual Studio cambió el encabezado del archivo de solución de:

 Microsoft Visual Studio Solution File, Format Version 11.00 # Visual Studio 2010 

A:

 Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio 14 VisualStudioVersion = 14.0.24720.0 MinimumVisualStudioVersion = 10.0.40219.1 

Volver a configurar la versión original de 2010 solucionó mi problema. Supongo que la compatibilidad con versiones anteriores en Visual Studio aún no se ha perfeccionado.

intente utilizar la “reparación” de Visual Studio. Funcionó para mí

Envoltura CMD
He intentado todas las cosas desde aquí y aún más. Nada me ayudó.

Apliqué un contenedor CMD para MSBuild y DevEnv.com.
La idea principal dentro de un contenedor de este tipo es crear un entorno preparado al invocar Comandos del suministro de Visual Studio. Y luego pase los parámetros de entrada estándar a una llamada de MSBuild o DevEnv.com.

De todos modos, en mi servidor de comstackción ahora puedo construir proyectos desde diferentes versiones de Visual Studio.

Cómo utilizar
Tuve que sustituir las llamadas a MSBuild y DevEnv por una llamada a mis contenedores de archivos por lotes.
Y no cambié ningún parámetro de entrada. Como un ejemplo para mi llamada contenedora MSBuild:

MsBuild_Wrapper.bat MySolution.sln /target Build /property:Configuration=Release

Solución lista
De hecho, tuve muchos más problemas con una migración de VS 2010 a VS 2015. Pero esta fue la primera y la más difícil.
Por lo tanto, mi modesta receta de rescate para Build Server está aquí. Posiblemente es difícil entender todo este estilo CMD allí desde el primer momento, pero cualquier lógica es obvia, espero.

Sugerencias
Existen
MSBuild Command Prompt for Visual Studio y Developer Command Prompt for Visual Studio
Los uso apropiadamente para MSBuild y DevEnv.com. Pero probablemente el símbolo del sistema de MSBuild sea suficiente.

Para VS 2015 esas instrucciones de comando están aquí C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\ . O mira a través del menú de progtwigs de Windows.

Para pasar todos los parámetros de entrada a MSBuild o DevEnv dentro de un archivo por lotes, utilicé CALL MSBuild %*