21

In Visual Studio 2003, I am trying to set an environment variable in the pre-build event that will then be used in the compilation step, but the value doesn't seem to be propagated. For example, if the pre-build event contains this (either directly or within a batch file):

set MY_LIB_VERSION=1.0.0

and AdditionalIncludeDirectories has this:

c:\path\to\library\my_lib_v$(MY_LIB_VERSION)\include

then I would expect the compilation to work if the my_lib_v1.0.0 directory exists. But instead, I get

c:\path\to\prog\my_prog.c(22) : fatal error C1083: Cannot open include file: 'my_lib.h'
Project : warning PRJ0018 : The following environment variables were not found:
$(MY_LIB_VERSION)

I deduce that the environment variable set in the pre-build event therefore isn't being propagated to the compilation step, but I may be missing something.

How can I set the environment variable in the pre-build event and use it in the compilation step?

(Alternatively, any other sensible ways of defining a library version once and using it several times for AdditionalIncludeDirectories and AdditionalLibraryDirectories would do just as well.)


Update: I ended up solving our problem in a different way. We are using Subversion, and set up the svn:externals property on a subdirectory of the project source called dependencies, such that a checkout of the project would additionally check out <svn_path>\libraries\my_lib_v1.0.0 and call it dependencies\my_lib in the working copy. Then the project settings could refer to dependencies\my_lib\include and suchlike. Upgrading to version 1.0.1 of my_lib is then simply a matter of editing the svn:externals property -- the code and project settings did not need to change.

Paul Stephenson
  • 67,682
  • 9
  • 49
  • 51
  • As of Windows 7 (so it seems) there is the command `SETX` to store environment variables persistently. Source: http://ss64.com/nt/setx.html – bassim Aug 14 '15 at 12:39

4 Answers4

10

It's 11 years later than when this question was originally asked. I am using VS 2019

if in the event you want to assign variables in your event like....

set ABC=123

Then you can't use $(ABC) as the $(ABC) is processed before it is handed to the command line to run.

You must use %ABC% as used by the command line. It doesnt know what $(ABC) is as it is only understood by visual studio.

To Further complicate things visual studio event editor uses % as an escape char. Ive noticed things starting %D are bad, %K, %Z and %K are good.

Apparently you can use %25 as the escape for %.

%DESTDIR% doesnt as the escaping garbles it - so changing it to %25DESDIR%25 fixes it.

AnthonyLambert
  • 8,768
  • 4
  • 37
  • 72
  • 1
    A comment after 11 years is worth an upvote. Though I could not get pre-build event command line `set` environment variables or debug command line arguments to pass to my Nunit test project. I had to [pass these directly to the tests](https://stackoverflow.com/questions/16276278/nunit-test-setup-method-with-argument) – rupweb Nov 26 '20 at 11:57
  • [Please don't](https://meta.stackexchange.com/q/104227/248627) [post](https://stackoverflow.com/a/61407715/354577) [multiple](https://stackoverflow.com/a/61407498/354577) [identical](https://stackoverflow.com/a/61407759/354577) [answers](https://stackoverflow.com/a/61407732/354577). If the questions are the same, flag them as duplicates. If they aren't, take the time to write a new answer _specific to the question being asked_. – ChrisGPT was on strike Feb 06 '21 at 13:30
6

I must admit that I've never attempted to set environment variables in a pre-build step, and I can see why it wouldn't necessarily work (running a batch file would most likely trigger a separate process, whereas you'd want to manipulate the parent process's environment).

A workaround I've been using, but which will only work when you can determine the necessary settings before starting Visual Studio, is to create a batch file that sets the necessary environment variables and then kicks off Visual Studio with the appropriate solution file. I've reproduced the skeleton of this batch file below:

REM
REM Set up VS environment with defaults (this is for 2008) - need to do this first
REM
call "C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
REM
REM Set the environment variables required by the project
REM
set BOOST_BASE=C:\Boost\include\boost-1_35
REM
REM If you need to manipulate the path, do it here
REM
REM
REM Finally, start VS with the appropriate solution file
REM
devenv MyProjectWithBoost.sln
Timo Geusch
  • 24,095
  • 5
  • 52
  • 70
  • Thanks for the workaround. We would know the version number in advance, but I really want to integrate it into the standard build so that the library version will be correct whether the developer uses the IDE or command-line. I don't have the power to make the whole team to use a special script! – Paul Stephenson Jan 07 '09 at 12:03
5

You might want to investigate this tool: http://workspacewhiz.com/SolutionBuildEnvironmentReadme.html

We use it all the time to manage environment variables in our build environment.

Paul Hollingsworth
  • 13,124
  • 12
  • 51
  • 68
  • Thanks. I've installed the Add-in and it works for me. I'm not sure whether I can persuade all our developers to install it themselves though, as it'll have to be done on every development machine to be reliable across the company. – Paul Stephenson Jan 07 '09 at 13:44
  • It does seem that an Add-in like this is the only way to edit Visual Studio's own environment variables, so I'll accept this answer even though it wasn't something I could apply across our company. – Paul Stephenson Sep 21 '09 at 13:06
  • This addin is great and is as far as I know the only solution to add env var dynamically. But note that the lines on your files containing the env vars mustn't exceed 2048 chars (there's an ugly char[2048] on the source code of the addin). – Grokwik Nov 03 '10 at 09:30
4

Environment variables which are set using the SET command are temporary and only last for the lifetime of the process in which they are set. They immediately expire when the process expires - and can't be seen by other processes.

A Visual Studio pre-build event is a separate process. Once that process expires that environment variable ceases to be.

Are you sure that environment variables are what you want? Could you do this by setting a value in a text file held on a central network location?

EDIT: If you really want to persistently change environment variables in Windows you can do it but it will involve calling into some Windows APIs rather than just calling SET. E.g. http://code.activestate.com/recipes/416087/

Try googling environment variable windows persisting

Sam Meldrum
  • 13,835
  • 6
  • 33
  • 40
  • The main thing I want to do is have a text file of library versions, and have the AdditionalIncludeDirectories dependent on the values in the text file, without requiring each developer to remember to run a special script before compilation. I'm not sure that environment variables are what I want! – Paul Stephenson Jan 07 '09 at 12:25