I'm on vista, with VS2005 running as admin. Both vs2005 and vs2008 are installed. If I explicitly use the path to gacutil, it works, but not if I only call gacutil like this:
if NOT $(ConfigurationName) == Release gacutil /f /i "$(TargetPath)"
I would just update the post-build script, but I've been asked to leave it alone. It's a project for a sister company. The path to gacutil is in Visual Studio environment variables, so it should be able to find it. (Tools -> Options -> Projects and Solutions -> VC++ Directories)
Is there some way to tweak visual studio or windows environment variable to get the above post-build script to work? I need to it to build, because it's a dependency of a project I need to code.
TIA, -j
As you suggest, tweaking the Windows PATH environment variable should get things working.
append the directory that contains GACUTIL to the end of the PATH. For example, using the location on my computer, append (without the quotes) ";C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin" to the existing value of the PATH system environment variable.
Restart Visual Studio to pick up the new value.
Dave
Related
Is there a way to just open a VS project from the command prompt? For example, the way with Atom, you can navigate to the folder you'd like to open and just run "atom ." Does that kind of utility exist for VS?
edit: Would the equivalent to this be "C:\> devenv /run SomeSolution.sln" ?
if so, great! But there still seems to be a problem because I think the "devenv" command should at least be recognized, but I currently get
'devenv' is not recognized as an internal or external command,
operable program or batch file.
I saw that a S/O contributer recommended adding
C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\devenv.exe
to the PATH environment variables values like this, per MSDN, which I did, but I get the same message.
Can anyone explain what might be going on and how to fix it? Thanks
You need to add new path to existing Path value.
Complete solution:
Go to MyComputer >> Properties >> Change Settings >> Advanced >> Environmental variables
Click on Path value on bottom pane, and then click Edit.
Add new path to your devenv.exe folder location.
For me this is "D:\Program Files\Microsoft Visual Studio Community 2017\Common7\IDE\"
This is much easier than it looks. Go to the root directory for the project, type the name of the .sln file, and hit Enter. Windows knows how to use the registry o find devenv.exe based on the extension of the file you run.
For example:
cd \Projects\SampleApp
SampleApp.sln
This technique is the same as if you opened the sln file by double clicking it in Explorer.
On similar issue, for VS 2017, I wanted to build a solution, below worked fine:
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe" Project.sln /build
VS 2019 Community
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe
Any Visual Studio Version
To find your specific devenv.exe path regardless of VS copy/version you can use cmd and then run:
cd \
dir /s divenv.exe
Note: The command dir /s may take a few minutes to find it.
Since I had no desire to update my PATH variable, I used the following steps to run devenv on the command prompt:
Navigate to the Visual Studio shortcut on the Start menu
Right-click the shortcut
Click on properties
Copy the path displayed in Target. This is the path to whatever version of devenv that you use.
Paste the copied path into the command prompt and press enter
I have a Jenkins slave with Visual Studio 2012 and want to build for x64. What I need is the prompt environment I get when I run the tools prompt link in the Windows Start Menu. People suggest to do it like this (in a Jenkins Windows Batch prompt):
call "%VS110COMNTOOLS%vsvars32.bat" x86_amd64
But this is not enough. There are small differences in the PATH, LIB and LIBPATH environment variables: the paths in there point to the x32 paths only, e.g. to
...;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN;...
instead of
...;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\x86_amd64;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN;...
In fact I am trying to build with the Ninja generator from CMake where the build configuration is determined by the prompt environment.
You need to call vcvarsall.bat x86_amd64 which is located in the VC-subdirectory (and eventually remove parentheses from the PATH):
set path=%path:"=%
call "%VS110COMNTOOLS%..\..\VC\vcvarsall.bat" x86_amd64
If you want to run this in a Pipeline script:
bat """set path=%path:\"=%
call "%vs110comntools%..\\..\\VC\\vcvarsall.bat" x86_amd64
..."""
Recently installed (and re-installed) VS 2012 Ultimate with Blend
The VS Command Prompt doesn't seem to have a reference (are they called environment pathways) to the folder "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\". This means the following lines won't run from the command prompt (either as normal or as administrator)
msbuild buildapp.csproj /t:HelloWorld
Installutil WindowsService1.exe
To use msbuild or Installutil I need to specify the full pathways for the above to run.
Is the above a by design change that MS have made to VS?
In my VS 2012 environment I can find the path you say is missing. I opened the "Developer Command Prompt for VS2012" and did PATH to verify and also ran InstallUtil.exe successfully.
Make sure you open the correct prompt, mine was started using %comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VsDevCmd.bat"
Here's Microsoft's explanation (err..justification :)) of the convoluted path structure :
For 32 bit builds :
Setting the Path and Environment Variables for Command-Line Builds
.. and 64 bit builds :
How to: Enable a 64-Bit Visual C++ Toolset on the Command Line
I am trying to use this tutorial from MS to verify I can build a .cpp file from the command line on my system. I seem to be having problems with my VS Command Prompt. It cannot find cl.exe or the needed include files. I added C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin and C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE to my path so it would find cl.exe. Now my error is:
test.cpp(1) : fatal error C1034: iostream: no include path set
Isn't the whole point of the VS Command Prompt to setup all these environment vars for me? Why isn't it setting it up properly?
I'm not sure exactly what your problem is but you might want to do the following to help determine the actual cause.
You may have noticed that the VS command prompt shortcut is a bat file. The first line is
#echo off
Change it to
REM #echo off
Run it again and see if you get any errors. If you don't it may be in one of the processor specific batch files to know which one that is look for the call to other batch like this.
C:\Program Files\Microsoft Visual Studio 10.0\VC>call "C:\Program Files\Microsof
t Visual Studio 10.0\VC\bin\vcvars32.bat"
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
Again REM out the #echo off in the batch and then run it again and see what errors you get.
Update from comment
The error ERROR: Cannot determine the location of the VS Common Tools folder
means your missing the Environment Variable %VS100COMNTOOLS% which is usually set to
"c:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\"
You can simply add it back using system properties -> Advanced -> New (under system variables)
See this superuser question for more on environment variables
I just figured it out. Thanks to Conrad Frix for the debugging tip.
It is surely due to some lovely security policy I have here on my workstation. Running the shortcut as administrator works. My account is a local admin account, but the admins do all kinds of weird stuff to our machines here...sigh. So, much of our development has to happen by "elevating".
Note, I was able to change the shortcut to run as under administrative privileges by selecting Properties->Advanced->Run as administrator.
Microsoft's C++ compiler and linker seem to have an odd relationship with mspdb100.dll. When run from the IDE, of course, the compiler and linker work fine. When running either one from the command line, I get an error.
No problem, I located the DLL and copied it to the directory. Now the compiler works fine, but the linker dies.
I could solve the problem by adding "%VS10%\Common7\IDE" to my PATH, but for various reasons (performance, system purity, OCD, etc), I don't want to do that. Why is this setup so touchy, and is there anything else I can do to solve it?
try running path\to\VC\bin\vcvars32.bat from within your current shell first. This should ensure your command-line setup will match the IDE-setup.
This is not a permanent fix -- you need to do it every time you launch a new shell.
You could probably also find some way to add everything that's in that .bat permanently to the environment variables, but.... like you asked, why the heck doesn't the MS install do that already?
Add Microsoft Visual Studio 10.0\Common7\IDE to your path, and this issue will not exist any more. You will be able to build without running this silly batch file every time.
I noticed when I installed Microsoft Visual Studio 2010 Express that under the "Microsoft Visual Studio 2010 Express" folder in the Start Menu, there is a link to "Visual Studio Command Prompt (2010)", which sets up all the necessary environment variables when opened. That way you shouldn't have to edit you PATH variable.
This shortcut runs the following:
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
If it's not convenient to use the shortcut, perhaps you could learn something of use from investigating what this .bat file does?
I met same error,it is because we installed a vs2010 x86 version to a x64 system...
Open two folders:
C:\Windows\Microsoft.NET\Framework\v4.0.30319
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin
You will find two cvtres.exe. Righ click, select Properties, then Details. Delete the older version, and cmake will work well.
I hope this may help you.
Thanks to "zhoudongao" # http://bbs.csdn.net/topics/390121452?page=1#post-394768226.
I know this is a bit dated but if anyone's looking for a way to get compiler running from command line; here's what I did to get it running.
I'm using Win7 32bit and Visual Studio 2010. I created a small batch file in C:\Windows. open cmd prompt at C:\Windows as admin, then type the following:
copy con cl.bat
#"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\vcvars32" %1 %2 %3 %4 %5 %6
#"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\cl" %1 %2 %3 %4 %5 %6
then press f6 and hit enter again.
Obviously the path you will use is the install path to where you installed Visual Studio.
You now have working command line compiler from any location or directory in windows. To test this go to desktop and open cmd prompt as admin; I prefer to use Ctrl+Shift and right click then choose open command prompt here.
At command prompt type "cl" (without quotes) and hit enter. you will see a message "Setting enviroment for using Microsoft Visual Studio 2010 x86 tools"
type "cl" and hit enter again and you will get your compiler info. you're all set to compile.
enjoy!
Maybe it will help somebody...
I solved this problem by adding
PATH += %PATH_TO_VS_IN_YOUR_SYSTEM%/Common7/IDE;
to nvcc.profile.
Of course, %PATH_TO_VS_IN_YOUR_SYSTEM% is actual path to Visual Studio in your system.
Old, but maybe still valid:
For me "C:\Windows\System32" somehow got missing from the PATH variable.
Adding the missing folder to the path solved this error. See also VS2010 command prompt gives error : Cannot determine the location of the VS Common Tools folder
if you try to run the tools from the windows cmd.exe directly then you need to set the environments by running the vcvars32.bat file which will set the environment for you. instead you can run the visual studio command prompt which will run vcvars32.bat automatically. if you still have the problem then it's definitely the famous path variable problem.
make sure the "path" variable in the environment has the "c:\windows\system32\" value added to it , because the .bat file will need it to configure the VC tools.
this problem and the like usually happen because of installing many development platforms on the machine which might probably change the path variable.
check this..
https://schrievkrom.wordpress.com/2011/01/25/error-cannot-determine-the-location-of-the-vs-common-tools-folder/