Related
On my PC I have created a system environment variable called 3DSMaxInstallDirectory
At the command line, if I give
echo %3DSMaxInstallDirectory%Plugins\
I get
D:\Program Files\Autodesk\3ds Max 2011\Plugins\
In Visual Studio I enter into the Post-Build section
copy "$(TargetDir)$(TargetName).*" "$(3DSMaxInstallDirectory)Plugins\"
However on build I get
Error 4 The command "copy "C:\Users\Sebastian\Documents\Visual Studio 2010\Projects\MaxBridge\MaxBridgeImporterPlugin\bin\Debug\MaxBridgePlugin.*" "Plugins\"
" exited with code 1. MaxBridgeImporterPlugin
The results on Google are a confusing mix of suggestions that Visual Studio doesn't support EVs, Visual Studio does support EVs, Visual Studio needs %..% and Visual Studio needs $(..) - and none of which seem to work on my computer.
What is the correct way to use my environment variable in Visual Studio?
(Yes, the directory exists, and the reason I don't want to set the path explicitly is I am preparing to share this project, and every step someone else has to take after downloading and before building is another barrier.)
This works for me in the Post-Build setting of the 'Build Events' of the project.
echo %CodeContractsInstallDir%
echo %DXSDK_DIR%
echo "%ONLYME%"
ONLYME is a environment var in the User variables of my profile.
The others are System wide vars.
ONLYME stays empty if I start VS2010 as administrator, the systemvars still have values as expected.
I'm on V2010 SP1
The '%' character is reserved by MSBuild, so you have to replace it by the %25 hexadecimal escape sequence as documented in MSDN.
copy "$(TargetDir)$(TargetName).*" "%253DSMaxInstallDirectory%25\Plugins" should actually work. However: Visual Studio's commandline editor displays it correctly, but MSBuild then interprets %253 wrongly. I can't tell whether it's a bug or a feature but you must not start your environment variable's name with a digit.
Visual studio doesn't properly encode/decode "special" characters in the XML config file. I'm able to get it to work as expected by manually escaping the command as a URL (http://www.w3schools.com/tags/ref_urlencode.asp).
ECHO %CD%
Results in an output log:
Target "PreBuildEvent" in file "blahblahblah"
Task "Exec"
Command:
ECHO %CD%
C:\blah\blah\blah\Debug
Done executing task "Exec".
However, using URL escapes in the project proerties dialog appears to work:
ECHO %25CD%25
According to this MS Link, the syntax is now the same as using a project file variable, which means you don't have to worry about escaping the % character anymore. For example, if BIN_PATH is an environment variable and the following line is added to the post build step:
echo $(BIN_PATH)
This line will then display the value of BIN_PATH to the output window after the build.
But, be aware that the environment variable must be defined before VS is started. I lost about 45 minutes when I first tried this before it dawned on me that maybe the reason why it was not working was because VS loads the environment variables on startup. So, I exited VS, restarted, and it worked like a charm.
You still might need the old % character syntax if your environment variable is the same as a VS project variable, since "the property in the project file overrides the value of the environment variable."
If you want to use an environment variable that is defined after VS is started, the rules differ for .vcxproj and .csproj projects. In .vcxproj projects, writing %MY_ENV_VAR% in the Project Properties won't work - you need to use the escape syntax %25MY_ENV_VAR%25. But a .csproj project does accept %MY_ENV_VAR%; using the escape syntax causes the escape sequence to be mangled, giving %2525MY_ENV_VAR%2525. (This in VS2017 at least.)
The debug tab of the project properties for a console application in VS2010 allows me to set command-line parameters to pass to the project whilst debugging.
I would like to set a parameter which is a path and the path is specific to each developer/machine, as it is a path which resides in the solution folder and each environment is different.
For pre- and post-build events, I can use macros such as $(ProjectDir), but I can't find a way to do this for command-line parameters - is there a way? A hack is fine, as long as it's not too awful!
Thanks
I haven't found a way to use $(ProjectDir) in the command line arguments, but you can access files contained within the project by:
Tell Visual Studio to copy specific files to the output directory by changing their "Copy to Output Directory" property.
Change your command line arguments from $(ProjectDir)/FileNeededDuringRuntime to FileNeededDuringRuntime.
This is more of a hack since it probably doesn't cover all the cases of using the variable, but it may get you by if you're just referencing a few files.
Macros can be used in command line arguments for C++ projects, see:
How to pass solution folder as parameter in command line arguments (for debug)?
You could have an empty C++ project "Set as StartUp Project" and change its "Configuration Properties -> Debugging -> Command" from "$(TargetPath)" (default for new projects) to "$(ProjectDir)..\OtherProjectRelativeDebugFolder\OtherProjectsOutputFileName.exe".
Since OtherProjectRelativeDebugFolder and OtherProjectsOutputFileName are relative and thus location independent you should be fine with that.
You said:
A hack is fine, as long as it's not too awful!
Is an empty project that produces an empty dll (unless you find a way to stop it, e.g. delete on post-build) too awful?
BTW. Environment variables aren't resolved in "Debug -> command line arguments" for C# either. I'll be experimenting on setting an environment variable, passing its name (because it isn't resolved) and reading it in the program. Passing the name is intended to show where the environment variable comes from, i.e. project settings.
Edit:
I hoped to find a way to set the environment variable to the value of a macro, e.g. in a build event. A simple shell "set" command is not persistent, so it didn't work out. Instead I was able to use a relative path as working folder to get things work for me. I also found a workaround that uses a file for persistent storage:
VS2010 - Project Macro Variables in Start Options Command Line Arguments
For example, I have 2 exe's. Let's call them 1.exe and 2.exe, to keep it simple.
And I want to make a zip file, with 3 things in it, 1.exe, 2.exe and setup.bat.
First off, I want to know that the user is okay that we start the first exe (1.exe). So we type:
#echo off
cls
echo Are you sure you want to install 1.exe?
echo If not, click exit right now. If you are okay with it,
pause
Here comes the first question. So we want to start 1.exe. How do I start 1.exe, that is in the same folder as the bat file?
Okay, lets continue. When 1.exe is finished, I want to copy 2.exe, place it in %appdata%, and then add it to startup. And that's the second question. How do i do that.
So the questions are:
How do I start 1.exe, which is in the same map as setup.bat
How do I copy 2.exe which is in the same map as setup.bat to %appdata%
How do I properly add 2.exe which is in %appdata% now to startup?
Note: Just using C:\documents and settings\all users\desktop\1.exe isn't going to work. I want it to work in all sorts of languages, and in some languages the folders might be called different.
1.exe will run 1.exe, just like on the command line.
copy 2.exe %appdata% will copy 2.exe.
I don't know what question 3 means.
Define "work in all sorts of languages"? If you need to pass in an argument to the batch file, do so: http://commandwindows.com/batch.htm
You are right you should never hard code "Documents and Settings" or "Program Files" in a BAT file, because these folder names don't "work in all sorts of languages". You need to refer to them using special folder ids or environment variables.
In your case, you need to create a program shortcut (.LNK file) in the startup folder. There are two parts.
creating a shortcut. Unfortunately there is no way to create a shortcut using only windows commands. You need to rely on a third party tool, there are many free command line tools that may do it; or write your own.
locating the Startup folder and placing the shortcut there. There are two startup folders. The common startup and the user startup folder. Choose one. Then, you need to use either the %ALLUSERSPROFILE%\Start Menu\Programs\StartUp or the %USERPROFILE%\Start Menu\Programs\StartUp.
So putting all pieces together in your SETUP.BAT , it would look something like this...
#echo off
echo Are you sure you want to install 1.exe?
echo If not, click exit right now. If you are okay with it,
pause
1
copy 2.exe %appdata%
makelink %appdata%\2.exe %USERPROFILE%\Start Menu\Programs\StartUp\2.lnk
One suggestion. Avoid all this mess. It seems to me that you need to install a program. If so, I'd recommend you to try Inno Setup. http://www.jrsoftware.org/ .
Inno Setup is a free installer for Windows. First introduced in 1997, Inno Setup today rivals and even surpasses many commercial installers in feature set and stability.
...
Supports creation of a single EXE to install your program for easy online distribution. Disk spanning is also supported.
Standard Windows 2000/XP-style wizard interface.
Customizable setup types, e.g. Full, Minimal, Custom.
Complete uninstall capabilities.
Installation of files: Includes integrated support for "deflate", bzip2, and 7-Zip LZMA/LZMA2 file compression. The installer has the ability to compare file version info, replace in-use files, use shared file counting, register DLL/OCX's and type libraries, and install fonts.
Creation of shortcuts anywhere, including in the Start Menu and on the desktop.
Creation of registry and .INI entries.
Running other programs before, during or after install.
...
This should do what you want.
#echo off
cls
echo Are you sure you want to install 1.exe?
echo If not, click exit right now. If you are okay with it,
pause
start /wait 1.exe
xcopy 2.exe %appdata% /y
reg add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "2" /d %appdata%\2.exe
The last line will make a reg entry instead of copying it to the startup folder which will not create a shortcut on the desktop and you don't need anything more than batch.
I would like to know what are the approaches that you use to manage the executables in your system. For example I have almost everything accessible through the command line, but now I come to the limit of the path string, so i can't add any more dir.
So what do you recommend?
A long time ago, I tried to use softLinks of the executables in a Dir that belonged to the path, but that approach didn't work.
Throw the "executable only" to a known Dir,has the problems that almost any application require a set of files, so this also is bad.
Throw the executable and all his files to a known Dir, mmm this will work, but the possibility to get a conflict in the name of the files is very very high.
Create a HardLink? i don't know. What do you think?
This will parse your %PATH% environment variable and convert each directory to its shortname equivalent and then piece it all back together:
#echo off
SET MyPath=%PATH%
echo %MyPath%
echo --
setlocal EnableDelayedExpansion
SET TempPath="%MyPath:;=";"%"
SET var=
FOR %%a IN (%TempPath%) DO (
IF exist %%~sa (
SET "var=!var!;%%~sa"
) ELSE (
echo %%a does not exist
)
)
echo --
echo !var:~1!
Take the output and update the PATH variable in environment variables.
One way I can think of is to use other environment variables to store partial paths; for example, if you have
C:\this_is_a\long_path\that_appears\in_multiple_places\subdir1;
C:\this_is_a\long_path\that_appears\in_multiple_places\subdir2;
then you can create a new environment variable such as
SET P1=C:\this_is_a\long_path\that_appears\in_multiple_places
after which your original paths become
%P1%\subdir1;
%P1%\subdir2;
EDIT: Another option is to create a bin directory that holds .bat files that point to the appropriate .exe files.
EDIT 2: Ben Voigt's comment to another answer mentions that using other environment variables as suggested might not reduce the length of %PATH% because they would be expanded prior to being stored. This may be true and I have not tested for it. Another option though is to use 8dot3 forms for longer directory names, for example C:\Program Files is typically equivalent to C:\PROGRA~1. You can use dir /x to see the shorter names.
EDIT 3: This simple test leads me to believe Ben Voigt is right.
set test1=hello
set test2=%test1%hello
set test1=bye
echo %test2%
At the end of this, you see output hellohello rather than byehello.
EDIT 4: In case you decide to use batch files to eliminate certain paths from %PATH%, you might be concerned about how to pass on arguments from your batch file to your executable such that the process is transparent (i.e., you won't notice any difference between calling the batch file and calling the executable). I don't have a whole lot of experience writing batch files, but this seems to work fine.
#echo off
rem This batch file points to an executable of the same name
rem that is located in another directory. Specify the directory
rem here:
set actualdir=c:\this_is\an_example_path
rem You do not need to change anything that follows.
set actualfile=%0
set args=%1
:beginloop
if "%1" == "" goto endloop
shift
set args=%args% %1
goto beginloop
:endloop
%actualdir%\%actualfile% %args%
As a general rule, you should be careful about running batch files from the internet, since you can do all sorts of things with batch files such as formatting your hard drive. If you don't trust the code above (which I wrote), you can test it by replacing the line
%actualdir%\%actualfile% %args%
with
echo %actualdir%\%actualfile% %args%
Ideally you should know exactly what every line does before you run it.
if you are using windows vista or higher, you can make a symbolic link to the folder. for example:
mklink /d C:\pf "C:\Program Files"
would make a link so c:\pf would be your program files folder. I shaved off 300 characters from my path by using this trick.
In case anyone's interested...
I find I never really need all those paths at once, so I create a bunch of "initialization" batch files which modify the path accordingly.
For example, if I wanted to do some C++ development in Eclipse, I would do:
> initmingw
> initeclipse
> eclipse
This is also handy for avoiding conflicts between executables with the same name (such as the C++ and D compilers, which both have a make.exe).
My batch files typically look like this:
#echo off
set PATH=C:\Path\To\My\Stuff1;%PATH%
set PATH=C:\Path\To\My\Stuff2;%PATH%
I find this approach relatively clean and have yet to run into any problems with it.
I generally don't have to worry about this (I haven't run into a path size limit - I don't even know what that is on modern Windows systems), but here's what I might do to avoid putting a program's directory in the path:
most command line utilities get thrown into a c:\util directory that's on the path
otherwise, I'll add a simple cmd/batch file to the c:\util directory that looks something like:
#"c:\program files\whereever\foo.exe" %*
which essentially creates an alias for the command. It's not necessarily perfect. Some programs really insist on being in the path (that's pretty rare nowadays), and other programs that try to invoke it might not find it properly. But for most uses it works well.
But generally, I haven't had to worry about avoiding adding directories to the path.
Another idea: Use DIR /X to determine the short names generated for non-8dot3 file
names. Then use these in your %PATH%.
For example, 'C:\Program Files' becomes 'C:\PROGRA~1'.
USe the App Path registry key instead of the path variable for application-specific paths:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx
I wrote and use on a every-time basis a standard stream (stdin/stderr/stdout) & exit code PROXY program (called dispatcher https://github.com/131/dispatcher)
All CLI program i use (node, php, python, git, svn, rsync, plink ...) i'm using are actually the same exe file (around 10kb, that i just name differently), that i put in the same directory. A dummy static clear text file do the "proxy file name to real exe mapping".
Dispatcher use low level Process management win32 API to be absolutly transparent.
Using this software, i only do have ONE additionnal directory set in my PATH for all programs i might use.
Creating a folder c:\bin adding to your path and hardlinking like you said could shorten the string. Maybe add a variable pf to system vars with value c:\Program Files then replace c:\Program Files with %pf% in path.
Edit:
Create a virtual drive.
subst p: "c:\program files"
I follow these steps to make the entries manageable:
Created different users for different combination of software packages usage.
Example: (a) Created a user web for making available all the web development software; (b) Created a user database for making available all the database and data warehousing software packages. Remember some software may create more than one entry. Or sometime I break this into oracle specific and MSSQL specific and oracle specific users. I put MySQL/PostgreSQL, tomcat, wamp, xamp all into the user account webr.
If possible install common packages like office, photoshop, .. as system specific available for all users and special packages as user specific. Of course I had to log into different users and install them. Not all software may provide this option. If "install for this user only" option is not available, install it for the whole system.
I avoid installing programs in to the folder Program File (x86) or in to Program File. I always install into the base directory. For example MySQL 64 bit goes into "C:\mysql64" and MySQL 32 bit goes into "C:\mysql" folder. I always assume adding a suffix 64 only for 64bit software. If no suffix, then it is a 32 bit. I follow the same thing to Java and others. This way my path will be shorter, not including "C:\Program File (x86)". For some software the configuration file may need to be edited to show where exactly the .exe file is. Only program that demands to be installed into "C:\Program File (x86)" will be installed into that folder. Always I remember to shorten the names. I avoid version number like tomcat/release/version-2.5.0.3 such details. If I need to the know version, I create a file by name version and put it into the tomcat folder. In general shorten the link as much as possible.
Include any batch to replace abbreviated link to the path, if all the above steps passed the Windows limit.
Then Log into usage specific (mobile application, or database/data warehousing or web-development.. ..) user and do the relevant tasks.
You can also create virtual windows within windows. As long as you have one licensed OS copy, creating multiple virtual windows with same key is possible. You can put packages specific for a particular task in that machine. You have to launch separate VM each time. Some memory intensive packages like 3D animation movie makers all should be put into the main machine, not into VM as VM will have only a part of the RAM available for its use. It is a pain to boot each VM though.
The solutions above only work if you can trim down your path. In my case, that wasn't really an option, and it was a hassle to have to run a script every time I opened a command prompt. So I wrote a simple script that runs automatically when opening the command prompt, and appends the contents of a text file to your path.
There are also some contexts where having this script run breaks things (say, in a github or cygwin shell), so I also added a file that contains a list of paths that, if the command prompt is started in them, the path variable isn't changed via the startup script that normally updates the path.
#echo off
:: Modify these to the actual paths of these two files
set dontSetupFile=C:\Users\Yams\Dontsetup.txt
set pathFile=C:\Users\Yams\Path.txt
:: Retrieve the current path (for determining whether or not we should append to our path)
set curDir=%cd%
:: Be done if the current path is listed in the dontSetupFile
SetLocal EnableDelayedExpansion
for /F "delims=" %%i in (%dontSetupFile%) do (
if "%%i"=="%curDir%" GOTO AllDone
)
:: Append the pathFile to our current PATH
set pathAppend=
for /F "delims=" %%i in (%pathFile%) do (set pathAppend=!pathAppend!%%i)
set PATH=%PATH%;%pathAppend%
:: The only way to actually modify a command prompt's path via a batch file is by starting
:: up another command prompt window. So we will do this, however, if this script is
:: automatically called on startup of any command prompt window, it will infinately
:: recurse and bad things will happen.
:: If we already ran, we are done
if "%yams%"=="onion" GOTO AllDone
:: Otherwise, flag that we just ran, and then start up a new command prompt window
:: with this flag set
set yams=onion
cmd \K set PATH=%PATH%;
:: When that command prompt exits, it will load back up this command prompt window, and
:: then the user will need to exit out of this as well. This causes this window to
:: automatically exit once the cmd it just spawned is closed.
exit()
:: Path is set up, we are done!
:AllDone
#echo on
And Path.txt will look something like
C:\Program Files (x86)\Google\google_appengine;
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\Program Files\Microsoft SQL Server\110\Tools\Binn;
C:\Program Files\Microsoft DNX\Dnvm;
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit;
While Dontsetup.txt will look something like
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit
C:\Program Files (x86)\Git\cmd
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin
To make this run automatically on startup, open regedit, navigate to HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command Processor, then right click on the right and press new -> Multi-String Value. Name it AutoRun. Set it's value to
C:\Users\Yams\setUpPath.bat
or wherever else you stored the batch file above.
Didn't try it, but will splitting PATH in parts work and joining them in final variable work?
Example initially let's say you have something like
PATH={LONGPATH1};{LONGPATH2};....{2048th char}....{LONGPATH_N-1};{LONGPATH_N}
Instead you create:
_PATH1 = {LONGPATH1};{LONGPATH2};....{2048 char}
_PATH2 = {2049th char}...{LONGPATH_N-1};{LONGPATH_N}
rem // may be more parts
PATH = %_PATH1%;%_PATH2%
I'm programming with Visual C++ Express on the command line using makefiles (GNU Make).
For this to work, I have to call the Visual Studio batch file vsvars32.bat to set up the environment. This has to be done everytime I open a new cmd.exe, before using make.
When I try to call the batch file from my makefile, it obviously executes the batch file as
an own process, because the environment is the same afterwards.
So my question: is there a way to execute scripts in cmd.exe like the built-in source command of the Linux/Unix bash? Apart from installing bash on Windows, of course.
Edit after posting my own answer:
The above question is not quite right, it should be like this:
Is it possible to call an environment-changing batch file from within a makefile, so that the changed environment persists for the other programs called in the makefile?
The answer to the original question is yes: you can use the built-in call command of cmd.exe. But since call is a built-in command and not a real program, it doesn't work in a makefile, only if you call a batch file from another batch file.
Answer compiled from the previous answers:
I made a batch file called make.bat which contains the following:
call "%VS90COMNTOOLS%vsvars32.bat"
call make.exe %*
This does the job.
But calling an environment-changing batch file from within a makefile, so that the changed environment persists for the other programs called in the makefile, seems to be impossible.
Edit: After overflowing my PATH variable by repeatedly calling vsvars32.bat, I made the following changes:
if not "%VISUALCVARS%" == "TRUE" (
set VISUALCVARS=TRUE
call "%VS90COMNTOOLS%vsvars32.bat"
)
call make.exe %*
use 'Call':
#echo off
pushd.
call "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars3235.bat"
msbuild LinqSupportClassesSDKBuild.csproj /t:rebuild /p:Configuration=Release /nologo /v:q /clp:ErrorsOnly;
popd
this is the cmd file we use to build our linq provider.
At least in my install of Visual Studio (albeit somewhat ancient VS .NET 2003), one of the links in the VS start menu group is to open a cmd.exe instance with the environment already setup. You might find these helpful:
How to Add Visual Studio Command Prompt (VSCP) to your IDE as a tool?
Running the command prompt from visual studio tools menu
Shortcut: Launch Visual Studio Command Prompt from Visual Studio
They are more geared toward launching the command prompt from the IDE, but they do include information on launching it with the appropriate environment as well which you may find helpful for your purposes.
How do you launch your console? If you are just launching 'cmd' then instead, create a shortcut that executes (%comspec% resolves to c:\windows\cmd.exe or whatever is relevent on your system)
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"" x86
Obviously, change the path to point to the proper installation folder.
More generally, as the above poster pointed out, if a .cmd file needs to process another .cmd file rather than launch it as a seperate process, use the 'call' batch command.
Wrap GNU make in a script (mmake.bat). Put the script in the path somewhere.
The script itself should run the vsvars32.bat and then make, like this
vsvars32.bat
make %*
As far as I remember, invoking a script from another script like this is done within the same shell (similar to Bash "." command).
I have found three solutions to this problem:
1) If the environment variables being set by the batch file are static (that is, they are always the same values), set those values for your entire user profile. Right-click on My Computer, click Properties-->Advanced-->Environment Variables. Add the variables from the batch file to the User Variables or System Variables section (User variables are only visible by you, System variables are visible by all users of that computer).
2) Write a wrapper batch file that calls the environment setup script then calls the Makefile.
3) Instead of using the SET command to set environment variables in the batch file, use the SETX command (requires the Windows Resource Kit). SETX is similar to SET, except it makes its changes to the master environment in the registry and will take effect in all command prompts launched in the future (but not the current one).