I've seen posts asking about how to get environment variables to be refreshed without having to close VStudio, but for me, I just want to know how I can make the changes without having to restart my system. I really don't understand how it can't detect the new changes - I've totally made sure the process is not hanging around and even used the vcvars32.bat to pick up new changes before re-opening. I can't find a solution. My environment variables can be used from elsewhere (ie. %variablename% works in cmd.exe). Any ideas?
The environment that is being used is the one from windows explorer. You would have to restart explorer for the changes to appear.
There is a way to apply the changes to the current environment. You might want to try SuperUser.com
Since the new environment variable is visible in the cmd window, why not start VS from there? The devenv command will start the VS IDE. You can tell it to load a particular solution or project.
devenv [solutionfile | projectfile | anyfile.ext] [switches]
The VS IDE will pick up the environment variable state that's in effect in that cmd window. However, note that certain environment variables will not be picked up unless you use the /useenv option:
/useenv: Use PATH, INCLUDE, LIBPATH, and LIB environment variables instead of IDE paths for VC++ builds.
Also note that it also accepts a bunch of options (mainly to build projects from the command line); use devenv /? to get details.
Related
C:\Users\redacted\Documents\redacted>gfortran hibrac.f -o hibrac.exe
'gfortran' is not recognized as an internal or external command,
operable program or batch file.
https://gcc.gnu.org/wiki/GFortranBinariesWindows seems similar to my problem: gfortran.exe is in C:\Windows\MinGW\bin -- except the solution appears not to apply to Windows 8.1 Pro:
Right click on My Computer, Properties, Advanced Tab, Environment Variables.
Instead I tried: Right click on 'This PC' within File Explorer, Properties, Advanced system settings, Advanced Tab -- and I cannot find an equivalent-looking section that allows me to proceed with the advised solution.
As background information:
I had installed MinGW Installation Manager which installed mingw32-gcc-fortran (together with mingw32-base, -gcc-g++, and -gcc-objc) in the recommended C:\Windows\MinGW folder, without any apparent error message.
Isn't it acceptable -- standard practice -- to have one's code in a folder separate from this MinGW folder? i.e. a subdirectory of my Users\account rather than a subdirectory of MinGW. This isn't the problem, is it? What do I need to do to get it to recognize the gfortran.exe, or call it correctly?
Please tell me what to do to get it working. If it's relevant, I have a Japanese computer with an English language pack installed (it seems to have some gaps, such as some text in the Settings charm or startup/shutdown text being in Japanese).
This looks very much like you have neglected to add C:\MinGW\bin to the effective PATH for the command window, in which you are attempting to run the gfortran command.
Your question isn't entirely specific on this point, (i.e. you could improve the question), but you hint that you were unable to add the appropriate PATH entry to the global environment variables, because you couldn't find the appropriate control panel applet? I know that this is often recommended as part of a MinGW setup, but the installer will not do it for you, because I, as the maintainer of mingw-get, don't consider that to be best practice; much better, IMO, to add it for each specific command window in which you need it to take effect, by running (once, at the start of each command prompt session) the command:
path %PATH%;C:\MinGW\bin
If you prefer, you may create a batch file to do this for you, along with any other initializations you wish to perform, (or better still, use MSYS as the working shell environment, in which case the PATH initialization is taken care of by the shell's own initialization scripts).
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).
I'm looking for a easy way to include application installation folder to a %PATH% environment variable after installation is complete.
Visual Studio 2005/2008/2010, Setup Project.
Thank you
Sad, but it still seems that you are right that it is required to code a class for the custom action. The example implementation has vanished. See below for an alternative.
This is an old question but still ranks high in google results.
The link in the accepted answer is now broken.
However, you can find a duplicate question (asked later) that still has accurate answers here:
GetEnvironmentVariable() and SetEnvironmentVariable() for PATH Variable
I flagged this question as duplicate but until it is closed here is the following code that worked for me:
string keyName = #"SYSTEM\CurrentControlSet\Control\Session Manager\Environment";
//get non-expanded PATH environment variable
string oldPath = (string)Registry.LocalMachine.CreateSubKey(keyName).GetValue("Path", "", RegistryValueOptions.DoNotExpandEnvironmentNames);
//set the path as an an expandable string
Registry.LocalMachine.CreateSubKey(keyName).SetValue("Path", oldPath + ";%MYDIR%", RegistryValueKind.ExpandString);
I replaced %MYDIR% with the application path.
In addition, you will need to make a custom action to house this code and place the code within the commit function.
The primary issue is that Visual Studio setups don't support the Windows Installer Environment table that can do all this with PATH and other environment variables. The MSI's Environment table isn't that complex, so it's worth using an MSI editor (such as Orca) to learn how to use it, then automate the MSI update with a post build step with a script (such as WiRunSql.vbs in the Windows SDK) to automate the update.
Alternatively, learn enough WiX to create a merge module containing the environment variables your setup needs, and add it to your Visual Studio setup.
Either of these choices is better than writing runtime code that requires care not to destroy the environment variables as well as not working for user variables in an Everyone install.
I have been playing with the Command Window in Visual Studio (View->Other Windows->Command Window). It is great for several mouse-free scenarios. (The autocompleting file "Open" command rocks in a non-trivial solution.) That success got me thinking and experimenting:
Possibility 1.1: You can use the Alias commands to create custom commands
Possibility 1.2: You can use the Shell command to run arbitrary executables and specify parameters (and pipe the result to the output or command windows)
Possibility 2: A previously setup external tool definition (with project-relative path variables) could be run from the command window
What I am stuck on is:
There doesn't appear to be a way to send parameters to an aliased command (and thus the underlying Shell call)
There doesn't appear to be a way to use project/solution relative paths ($SolutionDir/$ProjectDir) on a Shell call
Using absolute paths in Shell works, but is fragile and high-maintenance (one alias for each needed use case). Typically you want the command to run against a file relative to your project/solution.
It seems you can't run the traditional external tools (Tools->External Tools...) in the command window
Ultimately I want the external tool functionality in the command window in some way. Can anyone see a way to do this? Or am I barking up the wrong tree?
So my questions:
Can an "external tool" of some sort (using relative project/solution path parameters) be used in the Command Window?
If yes, How?
If no, what might be a suitable alternative?
StudioShell is another good, powerful, option. There's nothing quite like navigating around your solution (and Visual Studio as a whole) as if it were a file system. Scriptable of course. I've just begun to scratch to surface of this tool.
Seems as if there may, indeed, be a (much) better approach.
How about a VS extension that embeds powershell into the IDE and allows one to use DTE (Visual Studio Automation Objects)?
Yeah. That would do the trick and much more.
"An interactive, scriptable shell?" you ask? "Yes!" I say.
Does VS have an environment variable for the path to the current solution?
For example, there is "%PathToWebRoot%" which is generally set to the "WebSites" directory in your VS project directory. The value of it can be changed in any number of ways. I'm wondering if there's a variable that changes each time you load a solution to point to it's root.
I'm creating unit tests that will potentially be run on different machines and one of the directions you have to set before the method is the AspNetDevelopmentServerHost. It's recommended not to hard code them, of course, but the recommended environment variable isn't necessarily where your site will be and isn't in this case.
VS has a lot of Macro variables that work from within VS. The one that gives you the full path to the solution is called $(SolutionDir). However, while this works from the Pre- and Post-build events (and, AFAIK, in the solution's MSBuild file), this is not an environment variable. If you think about, you can't have a (global) environment variable that points to "the path to the current solution", since you may have more than one instance of VS open.
Depending on your unit testing framework, you can often ask it about its execution context to get the current directory. That may not give you the solution path, though...
Visual Studio does expose an environment variable for the solution path - it's called SolutionPath. It looks like this:
SolutionPath=D:\Team\MyProject\main-branch\MyProject.sln
Importantly, you can use it in any process spawned from Visual Studio - for example, launching batch scripts from your solution (that's how it can be different across different instances of Visual Studio).
If you configure Visual Studio to launch .bat files by double clicking on them by following this guide, then the environment variable will be available in your batch file.
In my particular case, I needed to get to a directory within my solution and I had a few branches of code all at the same level. But my batch script was at a higher level in the source tree and it had no easy way of determining the 'current' branch. For example, this was my structure:
D:\Team\MyProject\
L-- Build
L-- MyBatchScript.bat
L-- main-branch
|-- MyProject.sln
L-- important-folder
L-- dev-branch
|-- MyProject.sln
L-- important-folder
I referenced MyBatchScript.bat as a solution item in each solution so I could launch it by double clicking on it.
To get the folder of the solution rather than the path to the solution file, I used a bit of DOS batch script magic:
FOR %%d IN (%SolutionPath%) DO SET SolutionFolder=%%~dpd
REM Now I can run a tool with the correct folder
mycustomtool.exe %SolutionFolder%important-folder