Register
Handmade Hero»Forums»Code»VCVarsAll permanent across all cmd
Peter
4 posts
VCVarsAll permanent across all cmd
1 year, 2 months ago Edited by Peter on Sept. 15, 2018, 4:16 p.m. Reason: Initial post
Anyway to make this a permanent change when you run this, so you dont need to run it everytime you open a new cmd window?
Ive got a bat file that I run from the external tools in Visual Studio. Thing is it opens a new cmd everytime its run, and if Im trying to rebuild the dll while the code is running, its got to wait a few seconds while vcvarsall reloads. Ive managed to do this on my old computer by putting in all the registry keys by hand, but it was a pain in the butt, and I dont remember exactly how I went about finding all the keys for it. And if youve ever looked at the vcvarsall.bat file, its really hard to figure out. I want a bat file that sets all those vars/paths permanently. Im using VS2013 if thatll help.
Im gonna go look for the registry paths, see if I can export and import the keys if I can get to that computer again. That might be quicker huh?
Thanks
Simon Anciaux
681 posts
VCVarsAll permanent across all cmd
1 year, 2 months ago Edited by Simon Anciaux on Sept. 15, 2018, 4:34 p.m. Reason: layout
I think that if you open a prompt, call vcvarsall.bat and launch Visual Studio from there (devenv.exe), your bat file won't need to call vcvarsall again.
Peter
4 posts
VCVarsAll permanent across all cmd
1 year, 2 months ago
That would be great Gonna try it when I get home Thanks
Mārtiņš Možeiko
1983 posts / 1 project
VCVarsAll permanent across all cmd
1 year, 2 months ago
Not sure why you talk about registry. To figure out environment variables you need, you can simply invoke "vcvarsall" and then "set" to see new env variables. The ones you need as a minimum are PATH, INCLUDE and LIB. Others depending on whether you use C# or other VS stuff.

But I would suggest not doing that. It will make using different versions of VS much more difficult. Also I have seen some other software break in mysterious ways because it loads dll from VS folders instead of what it expects.

Instead do what mrmixer suggests - launch devenv from environment that has already necessary env variables set by vcvars.