I have installed VS2010. The installation creates the shortcut for VS2010 command prompt but when I open up the command prompt I get the error:
Cannot determine the location of the VS Common Tools folder.
I checked the environment variable VS100COMNTOOLS and it has value: C:\Program Files\Microsoft Visual Studi开发者_开发技巧o 10.0\Common7\Tools\
and the registry for HKEY_local_Machine\Software\Microsoft\Visual Studio\SxS\VS7
is set to: C:\Program Files\Microsoft Visual Studio 10.0\
.
I checked the VSvars32.bat and tried to add echo to find till where it proceeds. It fails at this command:
@call :GetVSCommonToolsDirHelper32 HKLM > nul 2>&1
I had the same issue and found the answer here.
The problem is that the bat uses de reg command and it searches that in the PATH system variable. Somehow you have managed to get "C:\Windows\System32" out of the PATH variable, so just go to the system variables (right click "My Computer" > "Properties" > advanced config > "Environment Variables", search the PATH variable and add at the end separated by ";" : C:\Windows\System32
I had the same problems in two machines: Win8.1x64 with Visual Studio Ultimate 2013 (VS2013) and Win8x64 with VS2013 ultimate
Problem: Shortcut "VS2012 x86 Native Tools Command Prompt" which points to file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat which calls C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\vcvars32.bat tries to search the registry for value name "11.0":
reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "11.0"
However my machine doesn't have this value "11.0", instead it has "12.0"
My solution is to run C:\Program Files (x86)\ Microsoft Visual Studio 12.0 \VC\vcvarsall.bat which calls C:\Program Files (x86)\ Microsoft Visual Studio 12.0 \VC\bin\vcvars32.bat which correctly query the registry as the following:
reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "12.0"
So changing/running from C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat to C:\Program Files (x86)\ Microsoft Visual Studio 12.0 \VC\vcvarsall.bat solved it in my case
This same problem just started occurring for me and I was able to "fix" it by updating the vcvars32.bat file located in the C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\ folder (by default). Add the following after the first line:
@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
And then comment out the following lines:
:: @call :GetVSCommonToolsDir
:: @if "%VS100COMNTOOLS%"=="" goto error_no_VS100COMNTOOLSDIR
:: @call "%VS100COMNTOOLS%VCVarsQueryRegistry.bat" 32bit No64bit
Found this here. Note that I say fix in quotes because I haven't checked to make sure that all the appropriate variables are set properly; that said, at a cursory glance it does appear to be valid.
Note that you'll have to edit the vcvars32.bat file in an elevated text editor (ie, Run as Admin) to be able to save the file in Vista and Windows 7.
The issue in my case was a typo in the PATH variable. Since vsvars32.bat uses the "reg" tool to query the registry, it was failing because the tool was not found (just typing reg
on a command prompt was failing for me).
That's a great post. Before making all the changes to vcvarsall.bat file, try running vs2010 command prompt as an administrator. If that still doesn't address the issue, try adding C:\Windows\System32 to the PATH environment variable. If all else fails, edit the batch file as described above.
I had this not too long ago as a result of registry editing being blocked by a group policy.
The specific problem is that reg is denied access to the registry. I solved this by replicating the 'reg.exe' using Microsoft.Win32.Registry
in a C# program, and then substituting all calls to reg, with my alternative program. You need to update:
- VCVarsQuery.bat
- VsDevCmd.bat
- VsVars32.bat
In the %VSxxxCOMNTOOLS%
folder (usually resolves to something like 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;
}
}
In cases like this, you can also use my alternative reg
implementation here.
I was facing same issue. I looked into environment variable for 'PATH' variable I could not found this. Then I added a variable 'Path' with "C:\Windows\System32" value. Everything is resolved now.
Direct the Paths to the correct locations on your computer. This setup assumes you have most programs installed in a central location(C:\Development). For my use I did not thus eliminating the need for 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%
Save file as a *.bat
run Visual Studio Command Prompt then execute *.bat.
This should fix all Environment Problems, so run configure
EDIT Almost forgot Credit where Credit is due: http://developer.qt.nokia.com/wiki/Building_Qt_Desktop_for_Windows_with_MSVC
I got same problem but different reason. I had "reg.bat" in the current directory. Renaming that into anything else solved the issue.
So, I figured out the root cause to all the problems in this thread. I originally thought it was specific to 2010 but the batch files for 2013 have the same token parsing syntax error. Basically, all of the batch files that MS distributes with their compilers from 2010 to at least 2013 have this same error. If you search all .bat files for this string
"%%i"
and replace it with
"%%j"
everything will work correctly. Basically they are trying to query the registry for different version entries to get the correct paths to use. They create a for loop that will iterate over the tokens from each line that the query pulls. There are three tokens that should come back. They use %%i for the first one which would be REG_SZ, to see if something was found. Then they use the same one to compare against a version string. They should be using %%j to get the second token which would be 8.0 or 10.0 or 12.0 and would actually yield a good comparison. Then they correctly use %%k to get the path associated with the version.
Again, do the simple search and replace in all the files that have a pattern like this:
@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"
)
)
and make it look like this:
@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"
)
)
by changing the second occurrence of %%i, which is in quotes, to %%j.
Hope this helps!
The same problem occurred for me when iI was installing a python library and it said unable to find the path of Visual Studio 2008/10. I have change the PATH from environmental variables. So to change it you the following process can be adopted: Start=> Computer=>Properties=>Advance System Settings=>Environment Variables=>System Variables. Here you will find path variable. If some already some path is set then you can use semicolon(;) to add the given path "C:\Windows\System32" else directly add the same.
I was getting the same error when trying to run a publish process through powershell on my build machine.
My build machine only has the Windows SDK installed and not Visual Studio and as such it appears that I'm missing some common files and registry values that are normally present when Visual Studio is installed. After looking into vsvars32.bat a bit more carefully I noticed that it was where the "Cannot determine the location of the VS Common Tools folder" error was being reported located under the GetVSCommonToolsDir label. It appears that in this batch file that since the VS7 sub-key doesn't exist on my machine it blanks out the %VS100COMNTOOLS% environment variable and reports back the specified error.
In my case it appears that this error is happening for me because I don't have Visual Studio or some other necessary components installed on my build machine and thus the registry key doesn't exist. Perhaps your error is due to something similar such as 32-bit vs 64-bit registry or 32-bit vs 64-bit VS command prompt? Testing the line of code that is failing from the batch directly in the command prompt should give you a clue about why the registry or file path isn't being resolved properly.
I had this problem when I installed something that created a user environment PATH variable. My TeamCity build agent was running as a service under my own username and it found the user PATH variable instead of the machine PATH variable. With the wrong path variable, it couldn't find much of anything and gave this error.
For me, this was caused by the PATH environment variable being set to an empty value for my user profile. The system variable was set correctly, so I deleted the blank PATH variable from my profile and everything worked again.
I got a gnarly beast working with only the Microsoft Windows SDK v7.1 batch file SetEnv.Cmd -- ie: I do not have Visual Studio vAny installed and did not have to use any of the specially prepared cmd prompts (where vsvars32.bat et al rear their ugly heads). I just have the Microsoft Windows SDK for Windows 7 (7.1) installed with their C/C++ compilers. On my Xp64 box, this is the sequence I used to be able to compile one of the June 2010 DirectX SDK Audio samples :
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
Note that using the Framework64 version of MSBuild.exe prevents me from building the X64 version (due to targets?), but the X86 version of MSBuild successfully built the X64 version of the same tutorial 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
I also have faced the same issue. Initially tried modifying System PATH which does not worked out. Later resolved by installing Micro Visual Studio express.
I ran into this same problem while doing a build on our Windows 7 build system. I was filling in for our build engineer's absence, and it was the first time I've done it since we migrated from Windows XP to Windows 7 32-bit. The IT requirements for our build system have locked the permissions down to where it's very difficult to do the most routine operations. As it turns out, the problem was due to a lack of elevated privileges. By closing Visual Studio 2010 and re-opening it with administrator rights (Run as Administrator), the problem was fixed.
So this is probably waaaaaay late to the party but the actual problem is an error or rather the repetition of the same error in three batch files.
C:\Program Files(x86)\Microsoft Visual Studio 10.0\Common7\Tools\VCVarsQueryRegistry.bat
C:\Program Files(x86)\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat
C:\Program Files(x86)\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat
The pattern of the error is everywhere a for loop is used to loop through registry values. It looks like this:
@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"
)
)
The problem is the second occurrence of %%i. The way the loop construct works is the first %% variable is the first token, the next is the second and so on. So the second %%i should be a %%j (or whatever you want) so that it points to the value that would possibly be a "10.0". You can tell the developer wanted to use i,j,k as the values because in the enclosed @SET in the if, they use %%k. Which would be the path.
So, in short, go through all these types of loops in the three files above and change the second occurrence of %%i to %%k and everything will work like it's supposed to. So it should look like this:
@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"
)
)
Hope this helps. Not sure if this applies to all versions. I only know that it does apply to VS 2010 (SP1).
None of the above fixed my problem.
I added "C:/Windows/System32" to the 'Path' or 'PATH' environment variable. I could use the reg /?
command. I also ran the 'vcvarsall.bat' file with no error message.
My error is that I was running VS2012 Cross Tools Command Prompt instead of VS2013 Cross Tools Command Prompt.
The reason being the file structure in the start menu. 2010 and 2012 are under 'Microsoft Visual Studio YEAR' and 2013 is under 'Visual Studio YEAR'. I just didn't realize this. :/
I hope this helps someone.
In my case I'd install VS.Net 2015 update 2 and left the Windows 8.1 SDK box UNchecked (since I'm now using Windows 10 and didn't think it necessary). However that seems to have resulted in some required registry settings being omitted.
Doing a modify of VS.Net 2015 from the control panel and checking the 8.1 SDK box fixed the problem.
Another cause can be VS 2013 Community Update 5 installing the WRONG SHORTCUTS; it installs VS 2012 shortcuts for VS 2013.
To fix it, edit the shortcuts. Rename them from 2012 to 2013, and change '11' to '12' in the path to vcvarsall.
See this microsoft social post.
I had same problem with Visual Studio 2010 on Windows XP. Just remove all constructions:
> nul 2>&1
from files:
\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat
\Microsoft Visual Studio 10.0\Common7\Tools\VCVarsQueryRegistry.bat
A simple solution to solve this issue both in vs developer command prompt and cmd is to add the following line
C:\Windows\System32
into the system path as follows:
My Pc-->properties-->Advanced-->Environment variables-->system variables hope it solves the issue.
My problem was a little bit different. As mentioned by @kzfabi - a registry entry is made to get details of the installed VS version. So the user executing the developer command line tools exe needs admin access as well as registry editing rights. In controlled environment set up by companies you may not have these rights and cause this error.
精彩评论