El símbolo del sistema VS2010 muestra un error: No se puede determinar la ubicación de la carpeta VS Common Tools

He instalado VS2010. La instalación crea el atajo para el símbolo del sistema VS2010, pero cuando abro el símbolo del sistema, aparece el siguiente error:

No se puede determinar la ubicación de la carpeta VS Common Tools.

Comprobé la variable de entorno VS100COMNTOOLS y tiene valor: C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\ y el registro para HKEY_local_Machine\Software\Microsoft\Visual Studio\SxS\VS7 se establece en: C:\Program Files\Microsoft Visual Studio 10.0\ .

Revisé el VSvars32.bat e intenté agregar echo para encontrar hasta dónde procede. Falla en este comando:

 @call :GetVSCommonToolsDirHelper32 HKLM > nul 2>&1 

Tuve el mismo problema y encontré la respuesta aquí .

El problema es que el murciélago usa el comando de reg y lo busca en la variable del sistema PATH. De alguna manera has logrado sacar “C: \ Windows \ System32” de la variable PATH, así que solo ve a las variables del sistema (haz clic derecho en “Mi PC”> “Propiedades”> configuración avanzada> “Variables de entorno”, busca la RUTA variable y agregar al final separados por ” ; “: C: \ Windows \ System32

Tuve los mismos problemas en dos máquinas: Win8.1×64 con Visual Studio Ultimate 2013 (VS2013) y Win8x64 con VS2013 ultimate

Problema: Acceso directo ” Símbolo del sistema de herramientas nativas de VS2012 x86 ” que apunta al archivo: C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 11.0 \ VC \ vcvarsall.bat que llama a C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 11.0 \ VC \ bin \ vcvars32.bat intenta buscar en el registro el nombre de valor “11.0”:

 reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "11.0" 

Sin embargo, mi máquina no tiene este valor “11.0” , sino que tiene “12.0”

Mi solución es ejecutar C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 12.0 \ VC \ vcvarsall.bat que llama a C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 12.0 \ VC \ bin \ vcvars32.bat que consultan correctamente el registro como el siguiente:

 reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "12.0" 

Así que cambiar / ejecutar desde C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 11.0 \ VC \ vcvarsall.bat a C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 12.0 \ VC \ vcvarsall.bat lo resolvió en mi caso

Este mismo problema acaba de comenzar a ocurrir para mí y pude “solucionarlo” actualizando el archivo vcvars32.bat ubicado en la carpeta C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 10.0 \ VC \ bin \ (de forma predeterminada) . Agregue lo siguiente después de la primera línea:

 @SET VSINSTALLDIR=c:\Program Files\Microsoft Visual Studio 10.0\ @SET VCINSTALLDIR=c:\Program Files\Microsoft Visual Studio 10.0\VC\ @SET FrameworkDir32=c:\Windows\Microsoft.NET\Framework\ @SET FrameworkVersion32=v4.0.30319 @SET Framework35Version=v3.5 

Y luego comenta las siguientes líneas:

 :: @call :GetVSCommonToolsDir :: @if "%VS100COMNTOOLS%"=="" goto error_no_VS100COMNTOOLSDIR :: @call "%VS100COMNTOOLS%VCVarsQueryRegistry.bat" 32bit No64bit 

Encontré esto aquí . Tenga en cuenta que digo corregir entre comillas porque no he verificado para asegurarme de que todas las variables apropiadas estén configuradas correctamente; Dicho esto, a primera vista, parece ser válido.

Tenga en cuenta que deberá editar el archivo vcvars32.bat en un editor de texto elevado (es decir, Ejecutar como administrador) para poder guardar el archivo en Vista y Windows 7.

El problema en mi caso fue un error tipográfico en la variable PATH. Dado que vsvars32.bat usa la herramienta “reg” para consultar el registro, estaba fallando porque no se encontró la herramienta (simplemente escribir reg en un símbolo del sistema me falló).

Esa es una gran publicación. Antes de realizar todos los cambios en el archivo vcvarsall.bat, intente ejecutar el símbolo del sistema vs2010 como administrador. Si eso aún no resuelve el problema, intente agregar C: \ Windows \ System32 a la variable de entorno PATH. Si todo lo demás falla, edite el archivo por lotes como se describe arriba.

Lo tuve hace poco tiempo como resultado de una edición de registro bloqueada por una política de grupo.

El problema específico es que a reg se le niega el acceso al registro. Lo resolví replicando el ‘reg.exe’ usando Microsoft.Win32.Registry en un progtwig C #, y luego sustituyendo todas las llamadas por reg, con mi progtwig alternativo. Necesita actualizar:

  • VCVarsQuery.bat
  • VsDevCmd.bat
  • VsVars32.bat

En la carpeta %VSxxxCOMNTOOLS% (generalmente se resuelve en algo como C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio XX.X \ Common7 \ Tools)

  static int Main(string[] args) { try { var targetRegistry = args[1].Substring(0, 4); var targetKey = args[1].Substring(5); string targetValue = null; if (args[2].ToLower() == "/v") { targetValue = args[3]; } else { return 1; } var hkey = targetRegistry == "HKLM" ? Registry.LocalMachine : Registry.CurrentUser; var key = hkey.OpenSubKey(targetKey); var result = key.GetValue(targetValue); Console.WriteLine(); Console.WriteLine(key.Name); Console.WriteLine(" {0} REG_SZ {2}", targetValue, key.GetValueKind(targetValue), result); Console.WriteLine(); Console.WriteLine(); return 0; } catch { return 1; } } 

En casos como este, también puedes usar mi implementación de reg alternativa aquí .

Estaba enfrentando el mismo problema. Busqué en la variable de entorno la variable ‘PATH’. No pude encontrar esto. Luego agregué una variable ‘Ruta’ con el valor “C: \ Windows \ System32”. Todo está resuelto ahora.

Dirige las rutas a las ubicaciones correctas en tu computadora. Esta configuración supone que tiene la mayoría de los progtwigs instalados en una ubicación central (C: \ Desarrollo). Para mi uso, no eliminé la necesidad de DEV.

 @ECHO OFF set DEV=C:\Development set QTDIR=%DEV%\Qt set PATH=%SystemRoot%;%SystemRoot%\system32;%QTDIR%\bin echo Setting OpenSSL Env. set OPENSSL=%DEV%\OpenSSL set PATH=%OPENSSL%\bin;%PATH% set LIB=%OPENSSL%\lib set INCLUDE=%OPENSSL%\include echo Setting NASM Env. set PATH=%DEV%\NASM;%PATH% echo Setting DirectX Env. set LIB=%DEV%\DirectX SDK\Lib\x86;%LIB% set INCLUDE=%DEV%\DirectX SDK\Include;%INCLUDE% echo Setting Windows SDK Env. set WindowsSdkDir=%DEV%\Windows 7.1 SDK set PATH=%WindowsSdkDir%\Bin;%PATH% set LIB=%WindowsSdkDir%\Lib;%LIB% set INCLUDE=%WindowsSdkDir%\Include;%INCLUDE% set TARGET_CPU=x86 echo Setting MSVC2010 Env. set VSINSTALLDIR=%DEV%\MSVC set VCINSTALLDIR=%DEV%\MSVC\VC set DevEnvDir=%VSINSTALLDIR%\Common7\IDE set PATH=%VCINSTALLDIR%\bin;%VSINSTALLDIR%\Common7\Tools;%VSINSTALLDIR%\Common7\IDE;%VCINSTALLDIR%\VCPackages;%PATH% set INCLUDE=%VCINSTALLDIR%\include;%INCLUDE% set LIB=%VCINSTALLDIR%\lib;%LIB% set LIBPATH=%VCINSTALLDIR%\lib echo Setting Framework Env. set FrameworkVersion=v4.0.30319 set Framework35Version=v3.5 set FrameworkDir=%SystemRoot%\Microsoft.NET\Framework set LIBPATH=%FrameworkDir%\%FrameworkVersion%;%FrameworkDir%\%Framework35Version%;%LIBPATH% set PATH=%LIBPATH%;%PATH% echo Setting Perl Env. set PATH = C:\Perl\bin;%PATH% echo Env. ready. title Qt Framework 4.8.0 Development Kit. cd %DEV% 

Guardar archivo como * .bat

ejecute el símbolo del sistema de Visual Studio y luego ejecute * .bat.

Esto debería solucionar todos los problemas del entorno, así que ejecuta configure

EDITAR Casi olvidé el crédito donde se debe el crédito: http://developer.qt.nokia.com/wiki/Building_Qt_Desktop_for_Windows_with_MSVC

Tengo el mismo problema pero una razón diferente. Tenía “reg.bat” en el directorio actual. Renombrar eso en cualquier otra cosa resolvió el problema.

Entonces, descubrí la causa raíz de todos los problemas en este hilo. Originalmente pensé que era específico para 2010, pero los archivos por lotes para 2013 tienen el mismo error de syntax de análisis simbólico. Básicamente, todos los archivos por lotes que MS distribuye con sus comstackdores desde 2010 hasta al menos 2013 tienen el mismo error. Si busca todos los archivos .bat para esta cadena

 "%%i" 

y reemplazarlo con

 "%%j" 

todo funcionará correctamente Básicamente están tratando de consultar el registro de diferentes entradas de versión para obtener las rutas correctas para usar. Crean un bucle for que iterará sobre los tokens de cada línea que extrae la consulta. Hay tres tokens que deberían volver. Usan %% i para el primero que sería REG_SZ, para ver si se encontró algo. Luego usan el mismo para comparar con una cadena de versión. Deberían estar usando %% j para obtener el segundo token que sería 8.0 o 10.0 o 12.0 y en realidad producirían una buena comparación. Luego usan correctamente %% k para obtener la ruta asociada con la versión.

De nuevo, haga la búsqueda simple y reemplace en todos los archivos que tienen un patrón como este:

 @for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "12.0"') DO ( @if "%%i"=="12.0" ( @SET "VS120COMNTOOLS=%%k" ) ) 

y haz que se vea así:

 @for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "12.0"') DO ( @if "%%j"=="12.0" ( @SET "VS120COMNTOOLS=%%k" ) ) 

cambiando la segunda aparición de %% i, que está entre comillas, a %% j.

¡Espero que esto ayude!

El mismo problema ocurrió cuando estaba instalando una biblioteca de Python y me dijo que no podía encontrar la ruta de Visual Studio 2008/10. He cambiado la RUTA de las variables ambientales. Entonces, para cambiarlo, se puede adoptar el siguiente proceso: Start => Computer => Properties => Advance System Settings => Environment Variables => Variables del sistema. Aquí encontrarás la variable de ruta. Si ya hay alguna ruta establecida, puede usar punto y coma (;) para agregar la ruta de acceso ” C: \ Windows \ System32 “; de lo contrario, agregue la misma.

Obtuve el mismo error al intentar ejecutar un proceso de publicación a través de powershell en mi máquina de comstackción.

Mi máquina de comstackción solo tiene instalado el SDK de Windows y no Visual Studio y, como tal, parece que me faltan algunos archivos comunes y valores de registro que normalmente están presentes cuando se instala Visual Studio. Después de examinar vsvars32.bat con más detenimiento, me di cuenta de que era donde se informaba el error “No se puede determinar la ubicación de la carpeta de herramientas comunes de VS” que se encuentra debajo de la etiqueta GetVSCommonToolsDir. Parece que en este archivo por lotes, dado que la subclave VS7 no existe en mi máquina, borra la variable de entorno% VS100COMNTOOLS% e informa el error especificado.

En mi caso, parece que este error me está sucediendo porque no tengo instalado Visual Studio u otros componentes necesarios en mi máquina de comstackción y, por lo tanto, la clave de registro no existe. Tal vez su error se deba a algo similar, como un registro de 32 bits frente a un registro de 64 bits o un símbolo de sistema de VS de 32 bits frente a uno de 64 bits. Probar la línea de código que falla del lote directamente en el símbolo del sistema debería darle una pista sobre por qué el registro o la ruta del archivo no se está resolviendo correctamente.

Tuve este problema cuando instalé algo que creó una variable PATH de entorno de usuario. Mi agente de comstackción TeamCity se estaba ejecutando como un servicio bajo mi propio nombre de usuario y encontró la variable PATH del usuario en lugar de la variable PATH de la máquina. Con la variable de ruta incorrecta, no pudo encontrar mucho y dio este error.

Para mí, esto fue causado por la variable de entorno PATH que se establece en un valor vacío para mi perfil de usuario . La variable del sistema se configuró correctamente, por lo que eliminé la variable PATH en blanco de mi perfil y todo volvió a funcionar.

Tengo una bestia descomunal que trabaja solo con el archivo por lotes Microsoft Windows SDK v7.1 SetEnv.Cmd , es decir, no tengo instalado Visual Studio vAny y no tuve que usar ninguna de las solicitudes cmd especialmente preparadas (donde vsvars32.bat et al rear sus feas cabezas). Solo tengo instalado el SDK de Microsoft Windows para Windows 7 (7.1) con sus comstackdores C / C ++. En mi cuadro Xp64, esta es la secuencia en la que solía comstackr una de las muestras de audio DirectX SDK de junio de 2010:

 REM open a regular old cmd.exe and run these 3 REM this builds the Win32 (ie: x86) version of the exe cd "C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Samples\C++\XACT\Tutorials\Tut02_Stream" "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /debug /x86 /xp "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" Tut02_Stream_2010.sln /p:Configuration=Debug /p:Platform=Win32 

Tenga en cuenta que el uso de la versión Framework64 de MSBuild.exe me impide crear la versión X64 (debido a los objectives?), Pero la versión X86 de MSBuild construyó con éxito la versión X64 del mismo tutorial tutorial:

 REM open a regular old cmd.exe and run these 3 REM this builds the X64 version of the exe cd "C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Samples\C++\XACT\Tutorials\Tut02_Stream" "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /debug /x64 /2003 "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" Tut02_Stream_2010.sln /p:Configuration=Debug /p:Platform=X64 

También me he enfrentado al mismo problema. Inicialmente intenté modificar System PATH que no funcionó. Más tarde se resolvió instalando Micro Visual Studio Express.

Me encontré con este mismo problema al hacer una comstackción en nuestro sistema de comstackción de Windows 7. Estaba completando la ausencia de nuestro ingeniero de construcción, y era la primera vez que lo hacía desde que migramos de Windows XP a Windows 7 de 32 bits. Los requisitos de TI para nuestro sistema de construcción han bloqueado los permisos hasta donde es muy difícil hacer las operaciones más rutinarias. Como resultado, el problema se debió a la falta de privilegios elevados. Al cerrar Visual Studio 2010 y volver a abrirlo con derechos de administrador (Ejecutar como administrador), se solucionó el problema.

Entonces, probablemente este sea tarde para la fiesta, pero el problema real es un error o más bien la repetición del mismo error en tres archivos por lotes.

C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 10.0 \ Common7 \ Tools \ VCVarsQueryRegistry.bat

C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 10.0 \ Common7 \ Tools \ vsvars32.bat

C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 10.0 \ VC \ bin \ vcvars32.bat

El patrón del error está en todas partes, un bucle for se usa para recorrer los valores del registro. Se parece a esto:

 @for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "10.0"') DO ( @if "%%i"=="10.0" ( @SET "VS100COMNTOOLS=%%k" ) ) 

El problema es la segunda aparición de %% i. La forma en que funciona la construcción de bucle es la primera variable %% es la primera ficha, la siguiente es la segunda y así sucesivamente. Entonces, el segundo %% i debería ser un %% j (o lo que quieras) para que apunte al valor que posiblemente sería un “10.0”. Puede decir que el desarrollador quería usar i, j, k como valores porque en el @SET incluido en el if, usan %% k. Cuál sería el camino.

Por lo tanto, en resumen, revise todos estos tipos de bucles en los tres archivos anteriores y cambie la segunda aparición de %% i a %% k y todo funcionará como debería. Por lo tanto, debería verse así:

 @for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "10.0"') DO ( @if "%%j"=="10.0" ( @SET "VS100COMNTOOLS=%%k" ) ) 

Espero que esto ayude. No estoy seguro si esto aplica a todas las versiones. Solo sé que se aplica a VS 2010 (SP1).

Ninguno de los anteriores solucionó mi problema.

Agregué “C: / Windows / System32” a la variable de entorno ‘Ruta’ o ‘RUTA’. Podría usar el reg /? mando. También ejecuté el archivo ‘vcvarsall.bat’ sin mensaje de error.

Mi error es que estaba ejecutando el símbolo del sistema de herramientas cruzadas de VS2012 en lugar del indicador de comandos de herramientas cruzadas VS2013 .

El motivo es la estructura del archivo en el menú de inicio. 2010 y 2012 están bajo ‘Microsoft Visual Studio YEAR ‘ y 2013 está bajo ‘Visual Studio Year ‘. Simplemente no me di cuenta de esto. : /

Espero que esto ayude a alguien.

En mi caso, instalaría la actualización 2 de VS.Net 2015 y dejaría sin marcar la casilla del SDK de Windows 8.1 (ya que ahora estoy usando Windows 10 y no lo consideré necesario). Sin embargo, parece que se han omitido algunas configuraciones de registro requeridas.

Hacer una modificación de VS.Net 2015 desde el panel de control y verificar el cuadro 8.1 SDK solucionó el problema.

Otra causa puede ser la Actualización Comunitaria VS 2013 5 instalando los ACCESOS A CORTO INCORRECTO; instala accesos directos VS 2012 para VS 2013.

Para solucionarlo, edita los accesos directos. Cambieles el nombre de 2012 a 2013, y cambie ’11’ a ’12’ en la ruta a vcvarsall.

Vea esta publicación social de microsoft .

Tuve el mismo problema con Visual Studio 2010 en Windows XP. Solo elimine todas las construcciones:

 > nul 2>&1 

de archivos:

 \Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat \Microsoft Visual Studio 10.0\Common7\Tools\VCVarsQueryRegistry.bat