L'invite de commande VS2010 indique une erreur: Impossible de déterminer l'emplacement du dossier VS Common Tools
J'ai installé VS2010. L'installation crée le raccourci pour l'invite de commande VS2010, mais lorsque j'ouvre l'invite de commande, le message d'erreur suivant s'affiche:
Impossible de déterminer l'emplacement du dossier VS Common Tools.
J'ai vérifié la variable d'environnement VS100COMNTOOLS et sa valeur est: C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\ et le registre pour HKEY_local_Machine\Software\Microsoft\Visual Studio\SxS\VS7 est défini sur: C:\Program Files\Microsoft Visual Studio 10.0\.
J'ai vérifié le fichier VSvars32.bat et j'ai essayé d'ajouter un écho pour savoir où il se déroulerait. Il échoue à cette commande:
@call :GetVSCommonToolsDirHelper32 HKLM > nul 2>&1
J'ai eu le même problème et j'ai trouvé la réponse ici .
Le problème est que la batte utilise la commande de reg et la recherche dans la variable système PATH. D'une manière ou d'une autre, vous avez réussi à extraire "C:\Windows\System32" de la variable PATH. Il vous suffit donc d'accéder aux variables système (cliquez avec le bouton droit sur "Poste de travail"> "Propriétés"> configuration avancée> "Variables d'environnement", recherchez le chemin variable et ajouter à la fin séparés par ";": C:\Windows\System32
J'ai eu les mêmes problèmes sur deux machines: Win8.1x64 avec Visual Studio Ultimate 2013 (VS2013) et Win8x64 avec VS2013 ultimate
Problème: Raccourci " Invite de commande d'outils natifs VS2012 x86 " qui pointe vers le fichier: C:\Programmes (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat qui appelle C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\vcvars32.bat tente de rechercher dans le registre le nom de la valeur "11.0":
reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "11.0"
Cependant, ma machine n'a pas cette valeur "11.0" mais elle a "12.0"
Ma solution consiste à exécuter C:\Fichiers de programme (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat qui appelle C:\Fichiers de programme (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat qui interroge correctement le registre de la manière suivante:
reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "12.0"
Donc, changer/en cours d'exécution à partir de C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat en C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat l'a résolu dans mon cas
Ce même problème vient tout juste de se produire pour moi et j'ai pu le "réparer" en mettant à jour le fichier vcvars32.bat situé dans le dossier C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\(par défaut). . Ajoutez ce qui suit après la première ligne:
@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
Et commentez ensuite les lignes suivantes:
:: @call :GetVSCommonToolsDir
:: @if "%VS100COMNTOOLS%"=="" goto error_no_VS100COMNTOOLSDIR
:: @call "%VS100COMNTOOLS%VCVarsQueryRegistry.bat" 32bit No64bit
Trouvé ceci ici . Notez que je dis fix entre guillemets car je n'ai pas vérifié pour m'assurer que toutes les variables appropriées sont définies correctement; Cela dit, à première vue, cela semble être valable.
Notez que vous devez éditer le fichier vcvars32.bat dans un éditeur de texte avec privilèges (c.-à-d. Exécuter en tant qu'administrateur) pour pouvoir enregistrer le fichier dans Vista et Windows 7.
Le problème dans mon cas était une faute de frappe dans la variable PATH. Puisque vsvars32.bat utilise l'outil "reg" pour interroger le registre, il échouait car l'outil était introuvable (il suffisait de saisir reg sur une commande, l'invite échouant pour moi).
C'est un excellent post. Avant d'apporter toutes les modifications au fichier vcvarsall.bat, essayez d'exécuter l'invite de commande vs2010 en tant qu'administrateur. Si le problème persiste, essayez d'ajouter C:\Windows\System32 à la variable d'environnement PATH. Si tout échoue, éditez le fichier de commandes comme décrit ci-dessus.
J'ai eu cela il n'y a pas si longtemps à la suite d'une édition de registre bloquée par une stratégie de groupe.
Le problème spécifique est que reg se voit refuser l'accès au registre. J'ai résolu ce problème en répliquant le 'reg.exe' à l'aide de Microsoft.Win32.Registry dans un programme C #, puis en substituant tous les appels à reg par mon autre programme. Vous devez mettre à jour:
- VCVarsQuery.bat
- VsDevCmd.bat
- VsVars32.bat
Dans le dossier %VSxxxCOMNTOOLS% (généralement résolu comme suit: C:\Program Files (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;
}
}
Dans de tels cas, vous pouvez également utiliser mon alternative reg implementation ici .
Je faisais face au même problème. J'ai examiné la variable d'environnement pour la variable 'PATH'. Je n'ai pas trouvé cela. Ensuite, j'ai ajouté une variable 'Path' avec la valeur "C:\Windows\System32". Tout est résolu maintenant.
Le même problème s’est produit pour moi lors de l’installation d’une bibliothèque python et j’ai indiqué qu’il était impossible de trouver le chemin de Visual Studio 2008/10. J'ai changé le PATH de variables environnementales. Donc, pour le changer, le processus suivant peut être adopté: Démarrer => Ordinateur => Propriétés => Paramètres système avancés => Variables d’environnement => Variables système. Ici vous trouverez le chemin variable. Si un chemin est déjà défini, vous pouvez utiliser un point-virgule (;) pour ajouter le chemin donné " C:\Windows\System32 ", sinon ajouter directement le même.
Ainsi, j'ai compris la cause fondamentale de tous les problèmes de ce fil. Je pensais au départ que cela était spécifique à 2010, mais les fichiers de commandes de 2013 ont la même erreur de syntaxe d'analyse syntaxique. Fondamentalement, tous les fichiers de commandes que MS distribue avec ses compilateurs de 2010 à 2013 au moins ont la même erreur. Si vous recherchez cette chaîne dans tous les fichiers .bat
"%%i"
et le remplacer par
"%%j"
tout fonctionnera correctement. Fondamentalement, ils essaient d’interroger le registre sur différentes entrées de version pour obtenir les chemins corrects à utiliser. Ils créent une boucle for qui va parcourir les jetons de chaque ligne extraite par la requête. Il y a trois jetons qui devraient revenir. Ils utilisent %% i pour le premier qui serait REG_SZ, pour voir si quelque chose a été trouvé. Ensuite, ils utilisent le même pour comparer avec une chaîne de version. Ils devraient utiliser %% j pour obtenir le deuxième jeton qui serait 8.0 ou 10.0 ou 12.0 et donnerait une bonne comparaison. Ensuite, ils utilisent correctement %% k pour obtenir le chemin associé à la version.
Encore une fois, faites la recherche simple et remplacez dans tous les fichiers qui ont un motif comme celui-ci:
@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"
)
)
et le faire ressembler à ceci:
@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"
)
)
en changeant la deuxième occurrence de %% i, qui est entre guillemets, en %% j.
J'espère que cela t'aides!
J'ai le même problème mais une raison différente. J'ai eu "reg.bat" dans le répertoire actuel. Renommer cela en quelque chose d'autre a résolu le problème.
Dirigez les chemins d'accès aux emplacements appropriés sur votre ordinateur. Cette configuration suppose que la plupart des programmes sont installés dans un emplacement central (C:\Development). Pour mon usage, je n'ai donc pas éliminé le besoin 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%
Enregistrer le fichier au format * .bat
lancez l'invite de commande Visual Studio, puis exécutez * .bat.
Cela devrait résoudre tous les problèmes d’environnement, alors lancez configure
EDIT Presque oublié Crédit où crédit est dû: http://developer.qt.nokia.com/wiki/Building_Qt_Desktop_for_Windows_with_MSVC
Pour moi, cela était dû au fait que la variable d'environnement PATH était définie sur une valeur vide pour mon profil utilisateur . La variable système a été définie correctement. J'ai donc supprimé la variable PATH vierge de mon profil et tout a fonctionné à nouveau.
Une autre cause peut être VS 2013 Community Update 5 en installant WRONG SHORTCUTS; il installe les raccourcis de VS 2012 pour VS 2013.
Pour résoudre ce problème, éditez les raccourcis. Renommez-les de 2012 à 2013 et remplacez «11» par «12» sur le chemin menant à vcvarsall.
J'ai eu ce problème lorsque j'ai installé quelque chose qui a créé une variable PATH d'environnement utilisateur. Mon agent de génération TeamCity était exécuté en tant que service sous mon propre nom d'utilisateur et il a trouvé la variable utilisateur PATH à la place de la variable ordinateur PATH. Avec la mauvaise variable de chemin, il ne pouvait pas trouver grand chose et donnait cette erreur.
J'ai rencontré ce même problème lors de la construction de notre système de construction Windows 7. Je remplaçais l'absence de notre ingénieur de compilation et c'était la première fois que je le fais depuis la migration de Windows XP vers Windows 7 32 bits. Les exigences informatiques de notre système de construction ont verrouillé les autorisations là où il est très difficile d'effectuer les opérations les plus courantes. En fin de compte, le problème était dû à un manque de privilèges élevés. En fermant Visual Studio 2010 et en le rouvrant avec des droits d'administrateur (Exécuter en tant qu'administrateur), le problème a été résolu.
J'ai aussi fait face au même problème. Initialement essayé de modifier System PATH, ce qui n’a pas fonctionné. Résolu plus tard en installant Micro Visual Studio Express.
Aucun de ce qui précède n'a résolu mon problème.
J'ai ajouté "C:/Windows/System32" à la variable d'environnement "Path" ou "PATH". Je pourrais utiliser la commande reg /?. J'ai également exécuté le fichier 'vcvarsall.bat' sans message d'erreur.
Mon erreur est que je courais VS2012 Invite de commandes de Cross Tools au lieu de VS2013 Invite de commandes de Cross Tools .
La raison en est la structure de fichier dans le menu Démarrer. 2010 et 2012 sont sous «Microsoft Visual Studio YEAR» et 2013 sous «Visual Studio YEAR». Je n'avais tout simplement pas compris cela. : /
J'espère que ça aidera quelqu'un.
C’est donc probablement tard pour le parti, mais le problème est une erreur ou plutôt la répétition de la même erreur dans trois fichiers de traitement par lots.
C:\Fichiers de programme (x86)\Visual Studio 10.0\Common7\Tools\VCVarsQueryRegistry.bat
C:\Fichiers de programme (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat
C:\Fichiers de programme (x86)\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat
Le modèle de l'erreur est partout où une boucle for est utilisée pour parcourir les valeurs de registre. Cela ressemble à ceci:
@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"
)
)
Le problème est la deuxième occurrence de %% i. La structure de la boucle fonctionne de la manière suivante: la première variable %% est le premier jeton, la suivante est la seconde et ainsi de suite. Ainsi, le second %% i devrait être un %% j (ou ce que vous voulez) afin qu'il pointe vers la valeur qui pourrait éventuellement être un "10.0". Vous pouvez indiquer au développeur qu'il souhaite utiliser i, j, k comme valeurs, car dans le @SET inclus dans le if, il utilise %% k. Quel serait le chemin.
En bref, parcourez tous ces types de boucles dans les trois fichiers ci-dessus et modifiez la deuxième occurrence de %% i en %% k et tout fonctionnera comme prévu. Cela devrait donc ressembler à ceci:
@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"
)
)
J'espère que cela t'aides. Pas sûr que cela s'applique à toutes les versions. Je sais seulement que cela s'applique à VS 2010 (SP1).
Une bête effrayante travaille uniquement avec le fichier de commandes Microsoft Windows SDK v7.1 SetEnv.Cmd -, par exemple: Visual Studio vAny n’est pas installé et je n’ai pas à utiliser les invites cmd spécialement préparées où vsvars32.bat et al élever leurs têtes laides). J'ai juste le SDK Microsoft Windows pour Windows 7 (7.1) installé avec leurs compilateurs C/C++. Sur ma boîte Xp64, voici la séquence que j'avais l'habitude de pouvoir compiler l'un des exemples audio de DirectX SDK de juin 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
Notez que l'utilisation de la version Framework64 de MSBuild.exe m'empêche de construire la version X64 (en raison de cibles?), Mais que la version X86 de MSBuild a réussi à créer la version X64 du même tutoriel exe:
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
Dans mon cas, j'installerais la mise à jour 2 de VS.Net 2015 en laissant la case SDK de Windows 8.1 décochée (étant donné que j'utilise maintenant Windows 10 et que je ne le pensais pas nécessaire). Cependant, il semble que certains paramètres de registre obligatoires aient été omis.
Le fait de modifier VS.Net 2015 à partir du panneau de commande et de cocher la case 8.1 SDK corrigeait le problème.
Une solution simple pour résoudre ce problème à la fois dans la commande vs developer, Prompt et cmd consiste à ajouter la ligne suivante
C:\Windows\System32
dans le chemin système comme suit:
Mon Pc -> Propriétés -> Avancé -> Variables d’environnement -> Variables système espérons que cela résoudra le problème.
La même erreur se produisait lorsque j'essayais de lancer un processus de publication via powershell sur ma machine de compilation.
Seul le kit de développement logiciel (SDK) Windows est installé sur ma machine de génération, et non Visual Studio. Il apparaît donc que certains fichiers communs et les valeurs de registre qui sont normalement présents lors de l'installation de Visual Studio sont manquants. Après avoir examiné le fichier vsvars32.bat un peu plus attentivement, j’ai constaté que c’est à ce stade que l’erreur "Impossible de déterminer l’emplacement du dossier VS Common Tools" était localisée sous l’étiquette GetVSCommonToolsDir. Il semble que dans ce fichier de commandes, étant donné que la sous-clé VS7 n'existe pas sur ma machine, elle efface la variable d'environnement% VS100COMNTOOLS% et renvoie l'erreur spécifiée.
Dans mon cas, il semble que cette erreur se produise pour moi, car Visual Studio ou d'autres composants nécessaires ne sont pas installés sur mon ordinateur de génération. La clé de registre n'existe donc pas. Votre erreur est peut-être due à quelque chose de similaire, comme un registre 32 bits vs 64 bits ou une invite de commande VS 32 bits ou 64 bits? Tester la ligne de code qui échoue depuis le lot directement dans la commande Invite devrait vous donner une idée de la raison pour laquelle le chemin du registre ou du fichier n'est pas résolu correctement.
J'ai eu le même problème avec Visual Studio 2010 sous Windows XP ..__, supprimez toutes les constructions:
> nul 2>&1
à partir de fichiers:
\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat
\Microsoft Visual Studio 10.0\Common7\Tools\VCVarsQueryRegistry.bat