La ejecución de MSBuild no puede leer SDKToolsPath

Hola, estoy teniendo un pequeño problema al ejecutar un script NAnt que solía construir correctamente mi sitio web basado en .Net 2.0, al compilar con VS2008 y sus herramientas asociadas. Recientemente actualicé todos los archivos de proyecto / solución a VS2010, y ahora mi compilació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" usando S dkToolsPath "" o el registro clave "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A". Asegúrese de que SdkToolsPath esté configurado y que la herramienta exista en la ubicación específica del procesador correcto debajo de SdkToolsPath y que el SDK de Microsoft Windows esté instalado

Ahora, tengo versiones anteriores (.Net 3.5) del SDK de Windows instaladas en el servidor de compilación, y el marco completo .Net 4.0 está instalado, pero no he encontrado 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 acabo de configurar una nueva variable ambiental "SDKToolsPath" y apunté a la copia de sgen.exe en mi carpeta sdk de Windows 6.0. Esto generó el mismo error, pero me hizo notar que a pesar de que la variable de entorno SDKToolsPath está configurada (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 comillas vacías).

La mayor parte de la información que he encontrado es específica de .Net 3.5 (o anterior). No hay mucho 4.0 relacionado 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?

Scott

Tuve que morder la bala e instalar VS 2010 en nuestro servidor de compilación para solucionar este problema. Por lo que puedo ver, no hay una versión 7.0A del SDK de Windows disponible en ningún lugar de MSDN. Sin embargo, la instalación de VS 2010 parece instalarlo, creando una clave de acceso 7.0A y una carpeta 7.0A en Archivos de programa \ Microsoft SDKs \ Windows.

No podría enfrentar poner Visual Studio en el servidor de compilació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 .

He instalado esto en mi servidor de compilación. Y luego, a través del símbolo del sistema del SDK de Windows 7.1 (Inicio => Todos los programas => Microsoft Windows SDK 7.1), configuré la versión predeterminada del SDK en 7.1.

Pasos:

cd Setup

WindowsSdkVer.exe -version:v7.1

Edite para incluir el comentario de LordHits: no es necesario instalar todo el SDK. Instalar solo las opciones "Desarrollo .NET / Intellisense y ensamblados de referencia" y "Herramientas / Desarrollo .NET" es suficiente.

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

msbuild.exe /p:GenerateSerializationAssemblies=Off

Paso manualmente las variables a MSBuild en el servidor de compilació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"

Encontré un problema similar recientemente en nuestro servidor de compilación.

Copié la carpeta 7.0A (C: \ Archivos de programa \ Microsoft SDKs \ Windows \ 7.0A) de mi computadora (que tiene VS2010 instalado) en el servidor de compilació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 si está confundido acerca de qué hacer con el registro en el servidor de compilación.

Me he encontrado con el mismo error pero en una situación diferente: usando VS 2010 Express e intentando usar la respuesta de Simmo para configurar explícitamente la versión del SDK; sin embargo, WindowsSdkVer.exe (herramienta de configuración de versiones) parece no apuntar a Express (comprensible ya que es limitado )

Estoy usando VS 2010 Express en Win 7 Prof. y siempre quiere usar v7.0A del Win SDK (que no tiene todos los exes necesarios), y no importa qué versión establezca explícitamente como actual usando WindowsSdkVer.exe (Sigue informando que configuró la versión actual del SDK pero para VS 2008, aunque solo tengo 2010 Ex instalado).

Entonces, mi solución barata fue instalar v7.0 WIN SDK (u otra versión como v7.1) y luego cambiar el nombre de su carpeta del sistema de archivos a v7.0A , ¡básicamente solo mentí a VS 2010 Express pero funciona ahora!

Uno de sus proyectos usa sgen.exe (Server Generator) para generar el servicio web. necesita instalar SDK para compilar el servidor o eliminar referencias del servicio web del proyecto.

Sospecho que el archivo de objetivos está anulando la ruta de las herramientas, eché un vistazo rápido en este archivo y establece SDKToolsPath en $ TargetFrameworkSDKToolsDirectory debajo de algunos de los objetivos allí. No creo que debas configurarlos en el entorno de todos modos, pero es posible que necesites arreglarlos en los archivos de tu 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 :(

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

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

Pero no pude construir proyectos .NET 4.0:

El 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 no poder) instalar el SDK de Windows 7 (porque eso también incluye el SDK de .NET 4.0), necesitaba instalar el SDK de Windows 8 y asegurarme de que esté instalado el "SDK de .NET Framework 4.5".

Es una locura ... pero funcionó.

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

Establecer en Sdk40ToolsPathlugar de SdkToolsPathespecificar una ubicación que no sea el directorio de instalación.

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

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

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 build y utilizamos Visual Build Pro 6 para compilar nuestro software. dado que algunos de nuestros desarrolladores usan VS 2010, los archivos del proyecto ahora contienen referencias a la "versión de herramienta 4.0" y, por lo que puedo decir, esto le dice a Visual Build que necesita encontrar un sdk7.x en algún lugar, aunque solo construimos para .NET 3.5 . Esto provocó que no encontrara lc.exe. Traté de engañarlo señalando 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í descargando e instalando SDK 7.1. Luego creé una clave de registro para 7.0A y apunté la ruta de instalación a la ruta de instalación del 7.1 sdk. ahora felizmente encuentra un "lc.exe" compatible y todo el código se compila bien. Tengo la sensación de que ahora también podré compilar 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:

<Project DefaultTargets="Do" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

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

Luego establezca rápidamente una nueva Variables de entorno en Variables del sistema. como abajo: "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.

Tuve este mismo problema e instalé Windows SDK 7.0 y Windows SDK 7.1 que tampoco solucionó el problema. La causa del problema para mí fue que la biblioteca de la clase infractora se creó con Target Framework de .NET Framework 2.0.

Lo cambié a .NET Framework 4.0 y trabajé localmente y cuando ingresé en el servidor Build lo construí con éxito.

Tuve un problema similar, en particular 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 decían que estaba actualizado, probablemente no lo estaba. Resolví el problema eliminando todas las versiones instaladas de SDK y luego instalando 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 manera de especificar la ruta a sgen.exe, utilizando SGenToolPath:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="14.0">
  <PropertyGroup>
    <SGenToolPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools</SGenToolPath>
  </PropertyGroup>

Su camino puede ser diferente, pero SGenToolPath es lo que desea.

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

Terminamos usando esta configuración SGenToolPath en el archivo .csproj, en lugar de editar los valores del registro en el servidor de compilación. La edición de los valores del registro en mi máquina local también funcionó, pero fue un poco más complicado y no queríamos meternos con el registro en el servidor de compilació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 $ (Registry: 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.

Yo también encontré este problema al intentar crear un complemento con Visual Studio 2017 en mi computadora de trabajo horriblemente desordenada. Si busca en Internet "no se puede encontrar resgen.exe", puede encontrar todos estos consejos que son como ' simplemente use regedit para editar su Registro de Windows y haga una nueva clave aquí y copie y pegue el contenido de esta carpeta en esta otra carpeta, bla, bla, bla. '

Pasé semanas simplemente estropeando mi Registro de Windows con regedit, probablemente agregué una docena de subclaves y ResGen.exe pegado con copia en muchos directorios diferentes, a veces colocándolo en una carpeta 'bin', a veces simplemente manteniéndolo en la carpeta principal, etc.

Al final, me di cuenta: "Oye, si Visual Studio daba un mensaje de error más detallado, nada de esto sería un problema". Entonces, para obtener más detalles sobre el error, ejecuté MSBuild.exe directamente en mi archivo * .csproj desde la línea de comandos:

 "C:/Windows/Microsoft.NET/Framework/v4.0.3.0319/MSBuild.exe C:/Users/Todd/Plugin.csproj -fl -flp:logfile="C:/Users/Todd/Desktop/error_log.log";verbosity=diagnostic"

Por supuesto, tendrá que cambiar los detalles de la ruta para adaptarse a su situación, pero asegúrese de poner 1) la ruta completa a MSBuild.exe 2) la ruta completa a su archivo * .csproj 3) el -fl -flp: archivo de registro = parte, que le indicará a MSBuild que cree un archivo de registro de cada paso que tomó en el proceso, 4) la ubicación en la que desea que se guarde el archivo * .log y 5); verbosidad = diagnóstico, que básicamente solo le dice a MSBuild para incluir toneladas de detalles en el archivo * .log.

Después de hacer esto, la compilación fallará como siempre, pero se quedará con un archivo * .log que muestra exactamente dónde MSBuild buscó su archivo ResGen.exe. En mi caso, cerca del final del archivo * .log, encontré:

Compiling plug-in resources (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.1a\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0a\WinSDK-NetFx40Tools-x86 (Task ID:41)
MSBUILD: error : Failed to locate ResGen.exe and unable to compile plug-in resource file "C:/Users/Todd/PluginResources.resx"

Básicamente, MSBuild buscó en cinco directorios separados ResGen.exe y luego se dio por vencido. Este es el tipo de detalle que simplemente no puede obtener del mensaje de error de Visual Studio, y resuelve el problema: simplemente use regedit para crear una clave para cualquiera de esas cinco ubicaciones y coloque el valor "InstallationFolder" en la clave , que debería apuntar a la carpeta en la que reside su ResGen.exe (en mi caso fue "C: \ Archivos de programa \ Microsoft SDKs \ Windows \ v10.0A \ bin \ NETFX 4.7.2 Tools").

Si usted es un experto en humanidades como yo sin experiencia en computadoras, puede tener la tentación de editar el registro de Windows y copiar y pegar ResGen.exe en todo el lugar cuando se encuentre con un error como este (que es por supuesto, mala práctica). Es mejor seguir el procedimiento descrito anteriormente: 1) Ejecute MSBuild.exe directamente en su archivo * .csproj para averiguar la ubicación exacta que MSBuild está buscando ResGen.exe y luego 2) edite su Registro de Windows precisamente para que MSBuild pueda encontrar ResGen. exe.

Lo arreglé pasando esto como parámetro de línea de comando a msbuild.exe:

Su kilometraje variará según la versión de SDK que tenga en su sistema

/p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools

Además de las modificaciones del registro, es posible que deba cambiar la versión de .net sdk en la configuración establecida 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 opciones de compilación avanzada de depuración

El Marco de destino (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. Había hecho un proyecto usando Visual Studio 2010y luego obtuve el error anterior cuando lo compilé usando Visual Studio 2012. Me sencillo copiar todo el contenido de C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0Adentro C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0Ay que resolvió mi problema.

Acabo de tener este error con un archivo .sln que se creó originalmente en Visual Studio 2010 (y está siendo creado por Visual Studio 2010 y TFS 2010). Modifiqué el archivo de solución para NO construir un proyecto que no se suponía que debía construirse 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

Configurarlo de nuevo a 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 usar la "reparación" de Visual Studio. A mí me funcionó.

CMD wrapper
He probado todas las cosas desde aquí y aún más. Nada me ha ayudado.

Apliqué un contenedor CMD para MSBuild y DevEnv.com.
La idea principal dentro de un contenedor de este tipo es crear un entorno preparado llamando a las solicitudes de comando desde el 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 compilación ahora puedo construir proyectos desde diferentes versiones de Visual Studio.

Cómo usar
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 ejemplo para mi llamada de contenedor 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 este fue el primero y el más difícil.
Entonces, mi modesta receta de rescate para un servidor de compilación está aquí. Posiblemente sea difícil entender todo este estilo CMD desde un primer momento, pero cualquier lógica es obvia, espero.

Consejos
Hay
MSBuild Command Prompt for Visual Studioy los Developer Command Prompt for Visual Studio
uso adecuadamente para MSBuild y DevEnv.com. Pero probablemente el símbolo del sistema de MSBuild sea suficiente.

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

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