La ejecución de MSBuild no puede leer SDKToolsPath


130

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


Problema relacionado en esta publicación. Publiqué una respuesta allí también. stackoverflow.com/questions/1109955/…
Diego C.

Respuestas:


15

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.


9
Prefiero no instalar Visual Studio 2010 en un servidor. Prefiero la sugerencia de Simmo a continuación de configurar el SDK de Windows actual a v7.1. WindowsSdkVer.exe se encuentra en C: \ Archivos de programa \ Microsoft SDKs \ Windows \ v7.1 \ Setup (suponiendo que esté instalado en C: \ Archivos de programa).
Philippe

55
He descubierto que si solo instala Windows SDK 7.1 y .NET 4.0. MSBuild no establece rutas adecuadas a SDK40ToolsPath y SDK35ToolsPath. Para solucionarlo, tuve que cambiar algunas entradas en HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0: "SDK40ToolsPath" = "$ (Registry: HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ Microsoft SDKs \\ Windows \\ v7 .1 \\ WinSDK-NetFx40Tools-x86 @ InstallationFolder) "Del mismo modo, cambie" v7.0A "a" v7.1 "en SDK35ToolsPath y FrameworkSDKRoot.
BlueMonkMN

77
Sheesh: ¡me encontré con el mismo problema nuevamente, busqué en Google y encontré mi propia respuesta! :) Algo parece haber restablecido mi cambio y supongo que tengo que aplicarlo manualmente nuevamente.
BlueMonkMN

3
ARRRGH! ¡Los últimos parches de .NET 4.0 (2011-08-11) sobrescribieron estas configuraciones de registro!
si618

8
Actualización sobre mi respuesta anterior. Parece que en sistemas operativos de 64 bits, también puede ser necesario actualizar valores similares en HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0, y puede ser necesario instalar el 8.0 SDK o actualizar los valores en HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 y HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 Hice todo lo anterior excepto la instalación del 8.0 SDK, y no pude compilar hasta que yo (como un lote paso) incluyó mis actualizaciones a todos los nodos 4.0 \ 11.0.
BlueMonkMN

227

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.


44
Esto funcionó perfectamente para mí, combinado con la copia a través de los archivos en C: \ Archivos de programa \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications desde mi máquina VS.
dnolan

1
¡Estaba enfrentando el mismo problema que el autor original y esta respuesta lo resolvió! No tuve que instalar Visual Studio 2010 en mi máquina Build.
SolutionYogi

37
Además, solo para aclarar, no es necesario instalar todo el SDK. Instalar solo las opciones "Desarrollo .NET / Intellisense y ensamblados de referencia" y "Herramientas / Desarrollo .NET" es suficiente. Esto y copiar los archivos del comentario de dnolan.
LordHits

Gracias por esta solución, ¡funcionó perfectamente para mí en nuestro servidor de compilación! Para su información, para cualquiera que esté cuestionando, el servidor de compilación es Windows Server 2008 x64.
Adam Weber el

Muchas gracias por esta respuesta; encontré el mismo problema en el trabajo con esto también.
Abe

20

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

msbuild.exe /p:GenerateSerializationAssemblies=Off

77
msbuild.exe / p: GenerateSerializationAssemblies = Off
Daniel

2
O configure "Generar ensamblaje de serialización: Desactivado" en la pestaña Generar de las propiedades del proyecto del servicio web.
Samneric

66
¿Qué hace esto exactamente?
enamorado

1
GOTCHA: Si lo apaga en la pestaña de compilación, asegúrese de hacer esto para la configuración de compilación que sea relevante (DropDown en la parte superior de la pestaña de compilación) en mi caso fue solo el servidor de compilación con el problema, así que tuve que cambie esto en la configuración 'Release'.
Myster

14
Me encanta cambiar aleatoriamente las banderas de compilación sin tener idea de lo que realmente hacen.
AaronLS

14

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"

1
Esto es lo que terminé haciendo para un SDK de Windows 10 en un servidor sin Visual Studio y Build Tools 2019. Ninguna de las otras soluciones parecía ayudar y esta hizo el truco de una manera limpia.
Nicolás Fantone

8

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.


Para mí, la respuesta de Simmo no funcionó; sin embargo, este hack de registro sí funcionó (Win 2K3 SP2).
FinnNk

7

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!


5

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.


1
O configure "Generar ensamblaje de serialización: Desactivado" en la pestaña Generar de las propiedades del proyecto del servicio web.
Samneric

1
GOTCHA: Si lo apaga en la pestaña de compilación, asegúrese de hacer esto para la configuración de compilación que sea relevante (DropDown en la parte superior de la pestaña de compilación) en mi caso fue solo el servidor de compilación con el problema, así que tuve que cambie esto en la configuración 'Release'.
Myster

4

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 :(


Correcto, NAnt aún no es compatible con los formatos de archivo de proyecto / solución para VS2010, por eso estoy llamando a MSBuild para el paso de compilación real. Verificará el archivo de objetivos.
Scott Mayfield

4

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ó.


Esto exactamente me ayudó en Windows 10 también.
bourbert

3

¿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.


1
Recuerde, este es un servidor de compilación, por lo que instalar el entorno VS2010 completo no fue mi primera opción. No pude encontrar ninguna descarga disponible del SDK de Windows 7.0a
Scott Mayfield

3
No veo el problema. Ejecutar una compilación en una máquina cuya configuración no coincide con las máquinas de desarrollo, ese es un problema que lo desgastará rápidamente.
Hans Passant

3

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í.


¿Dónde configuró Sdk40ToolsPath?
Michael Freidgeim

Supongo que debe agregarse a la ruta del entorno. Sin embargo, no funcionó para mí.
Timothy Lee Russell el

Lo siento, esto fue hace mucho tiempo. Olvidé los detalles, pero creo que fue una variable de entorno o se configuró en el archivo del proyecto MSBuild. También tenga en cuenta que la pregunta original se relaciona con .NET Framework 4.0 / VS2010, pero es posible que se necesiten diferentes variables para versiones posteriores de framework.
IanS

2

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ó.


2

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.


2

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">

Bueno, en mi caso utilicé ToolsVersion = "14.0" para VS 2015 y esto resolvió el problema
AndrewSilver

2

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.


Esto está resolviendo el problema. Solo una pista si alguien tiene el mismo problema que yo. ¡La variable Env debe llamarse TargetFrameworkSDKToolsDirectory y no SdkToolsPath!
Markus

1

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.


1

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


1

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.


1

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.


Intenté esto, pero por alguna razón no obtengo la lista de rutas que muestra. Encontré una publicación similar a la suya en este sitio: community.sdl.com/developers-more/developers/…, así que sé que debería funcionar, pero fue en vano. ¿Qué versión de MSBuild estás usando?
user11809641

Parece que estoy usando MSBuild versión 4.0.30319. También tengo instalada la versión 3.5, 3.0 y 2.0.50727 en esta computadora. Traté de ejecutar esas versiones de MSBuild en mi archivo * .csproj (de la misma manera que se describe anteriormente), pero no funcionó ... ni siquiera creó un archivo * .log. /// Cuando ejecuta MSBuild en su archivo * .csproj, ¿la computadora al menos produce un archivo de registro *? Entiendo que hay un archivo de registro, simplemente no hay información específica sobre las rutas que se buscaron al buscar ResGen.exe, ¿es correcto?
todbott

Parece que tengo la misma versión de MSBuild (4.0.30319). Y si, tienes razón. Recibo un archivo de registro, pero no proporciona ninguna información sobre las rutas de registro. ¿Cuál de las cinco rutas que publicaste anteriormente terminaste usando?
user11809641

Utilicé la primera ruta de la lista: acabo de agregar un "Carpeta de instalación" en la clave SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86. Además, el archivo * .log es realmente extremadamente largo: miles de líneas, en mi caso. No pude encontrar la información del camino a simple vista. Terminé abriendo el archivo * .log en el Bloc de notas y buscando "ResGen.exe", lo que me llamó la atención sobre el área pertinente (información de rutas).
tobott el

1
Super - felicidades! Te has convertido en una de las pocas personas (algunos cientos, supongo) que han luchado a través de los errores y el misterio y en realidad compilaron con éxito un complemento para Trados. ¡Buena suerte con la publicación de tu complemento, nos vemos en la SDL Appstore!
todbott

1

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

0

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ó.


Cometí un error, se encuentra en lo siguiente. Proyecto => Propiedades de la barra de herramientas => Botón Compilar Opciones avanzadas de compilación También creé un nuevo proyecto y el nuevo proyecto .net se configuró en 3.0. Por lo tanto, también será necesario cambiar la configuración predeterminada. Scott A. Tovey
Scott Tovey

Descubrí que cuando creas un proyecto, en la parte superior de la ventana hay una lista desplegable de todos los marcos. Todo se enumera independientemente de si está instalado o no. Una vez que selecciona un marco y crea un proyecto de esa lista, sigue siendo el predeterminado hasta que lo cambie a otro marco para un nuevo proyecto. Esto es un poco imprudente, la lista solo debe contener marcos que estén instalados en el sistema.
Scott Tovey

0

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.


3
Desearía que se votara por la peor solución del mundo. Esto seria todo.
jonypony3

0

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.


0

intente usar la "reparación" de Visual Studio. A mí me funcionó.


0

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 %*

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.