Home Dashboard Directory Help
Search

persistent configuration of environment for VC command line tools by Piotr Dobrogost


Status: 

Closed
 as Won't Fix Help for as Won't Fix


1
0
Sign in
to vote
Type: Suggestion
ID: 433711
Opened: 4/20/2009 4:10:35 AM
Access Restriction: Public
0
Workaround(s)
view

Description

There should be a way to configure environment of VC command line tools in a persistent way. Current solution (vsvarsall.bat) is not persistent and one has to run it each time new shell window (command line) is opened.
The problem is also when running some 3rd party tools (cmake-gui) directly from Start/Programs as there's no way of running vsvarsall.bat in this case.

Additionally to providing persistent way of setting environment there should be a tool to revert settings made to environment.

Discussion of this problem is here:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/deb76102-7977-4e71-8e13-7da8cc990997
Details
Sign in to post a comment.
Posted by Microsoft on 5/4/2009 at 12:05 AM
Hello Piotr,

thanks for taking the time to send us feedback.

As you've seen from the community discussion, you should be able to solve this problem via additional cmd scripts. You can call vsvarsall.bat from your own scripts (you can see inside vsvarsall.bat to get an idea of how to do that). The MSDN forums (http://forums.microsoft.com/msdn/default.aspx) are a great resource as well.

HTH,
Ale Contenti
VC++ Dev Lead
Posted by TemporalBeing on 4/28/2009 at 9:51 AM
Piotr,

My suggestion is not for something that would be "persistent" - just a way to quickly switch between environments within the same command shell. It would satisfy what you want as the single batch file (e.g. msvs_env.bat) would be accessible from the default PATH - so you would be able to simply open a command shell and call it to get the one you want. It also allows for more than one version of VS to be installed. All-in-all, it has nothing to do with a persistent environment, but easy and scriptable access to the desired environment. - something that would be far more likely to be supported than a 'persistent' environment; it would also likely have a lot larger user base, desire for usage, and ability to maintain it.
Posted by Piotr Dobrogost on 4/21/2009 at 11:00 AM
"Direct support for this kind of thing from Microsoft would be very beneficial."

I agree. I heard setting environment for command line tools in a persistent way was possible in VS6 but it was removed in all newer versions.
Posted by Microsoft on 4/21/2009 at 6:02 AM
Thanks for reporting this issue. We are escalating this suggestion to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Posted by TemporalBeing on 4/20/2009 at 6:46 AM
I presently manage several installations of VS through a couple batch files - one of which controls the environment. The batch file both setups up and tears down a VS environment. Perhaps it would be helpful for Microsoft to provide such a utility that could be put in the standard path and support the various versions of VS; thus one would not have to remember to use the special VS Command-line Short-cuts to get the environment, or have to go about figuring out where the appropriate VS batch file is.

My utility has the following interface:

msvs_env.bat <environment>
msvs_env.bat --reset

I am only supporting the environments that I use - and the <environment> may be one of the following:

build_VS6
build_2003
build_2008

So I run "msvs_env.bat build_2003" to setup the command-line environment for the VS .Net 2003 compiler. When I want to switch compilers, the utility automatically resets the environment before initializing the environment for the next compiler. The user can also reset the environment themselves by running "msvs_env.bat --reset".

The environmental initialization searches the registry for the installation path of VS and then runs the appropriate batch file. It also saves a copy of the PATH environment variable.

The environmental reset explicitly unsets all environment variables modified by the initialization - removing them from the environment - and resets the PATH to what it was before the script was run.

This seems to be a simple solution that can manage multiple environments. Direct support for this kind of thing from Microsoft would be very beneficial.
Sign in to post a workaround.