The Auto Build Environment add-in uses a new file called
SolutionName.slnenv residing in the same directory as the solution to
provide build environment variables tailored to a given solution file.
.slnenv stands for "solution environment." The Auto Build Environment add-in
executes this file at solution open time and before the start of each
build, resetting the build's environment variables accordingly.
I often have the need to set environment variables used for builds before launching Visual
Studio .NET. My most common usage of environment variables is that of storing a machine dependent path,
typically for the Preprocessor Include settings. However, I also use them
for additional command-line options to the compiler.
Rather than tweaking each machine's global environment variables, I provide
my customers a batch file that launches Visual Studio .NET. This requires a little bit of trickery and a utility for
reading registry entries (such as DtReg at
http://www.tamedos.com/downloads/downloads.htm). The VS.NET launching
batch file is shown below:
for /f "tokens=1*" %%i in ('c:\dtreg -lv %rp%') do set VSDir=%%j
start /D"%VSDIR%" devenv.exe %*
My custom build settings are stored in an additional batch file that launches
the specific solution.
set EXTRA_OPTS=/D MY_DEFINE
call StartVisualStudioNET.bat %cd%\AnotherDirectory\MySolution.sln
Each project needing these build settings would add
$(MYPATH) into the Preprocessor Includes and
$(EXTRA_OPTS) to the additional command line arguments.
While it is bearable to launch Visual Studio .NET from a batch file with
custom build settings, it is certainly not convenient. Worse, it requires
shutting down the IDE for each new build environment. I needed a better
way, and thus, the Auto Build Environment add-in was born.
New versions of the Auto Build Environment add-in may be found on
http://workspacewhiz.com/ in the Misc.
Installation without the Installer
- Unzip the archive.
- Close down Visual Studio .NET.
- Reopen Visual Studio .NET.
The installer offers much more ease of use and should be used where possible.
Inside the SolutionName.slnenv file, with one entry per line, are
The solution's path is available via a variable called
The solution directory does not contain a terminating backslash.
The solution's name is available through
Environment variables may be inserted using the
syntax. This has the same functionality as a batch file's
Simple registry entries may be accessed via
Only string values may be retrieved.
An environment variable may be applied onto a specific Solution
Configuration. The syntax for this is
Other .slnenv files may be included using the
forceinclude keywords. The filename
following each keyword should not contain the .slnenv extension.
Comments are specified by using
-- at the beginning of the line.
-- This is a comment.
Assume you are building a DirectX application called Game, but the DirectX
include directory is not at the same location across different machines.
(Normally, the DirectX include directory is global, but this may not always be
the case.) This is a good example of creating a per user .slnenv
file. First, we put a Game.slnenv file in the same directory
-- Provide a reasonable default.
-- Call the user .slnenv file so it can override.
-- We don't use forceinclude so this is optional.
-- Now, build the compile options.
The UserDXPath.slnenv file may look like this:
-- The DirectX SDK is actually at the d:\Program Files\DXSDK directory.
When the Game.sln file is run, the environment variable
DXPATH is available to it via
COMPILE_OPTS is available via
$(COMPILE_OPTS) is inserted into the Command-Line Options property
page, the build uses your DirectX directory.
Auto Build Environment was written in C++ with ATL support for the add-in.
It demonstrates the use of patching into the Solution Events and Build Events
objects. It also demonstrates additional code that may be inserted into
install and uninstall the add-in registry entries without additional install
The build environment technique works because add-ins run in the same process space as Visual
Studio's devenv.exe. Builds launched from the IDE inherit the environment
of devenv.exe. Calling the Win32
function call allows manipulation of the IDE environment. Previous to
setting the new environment variable, the old one is retrieved using
GetEnvironmentVariable() and stored, allowing each solution session to
work in a pristine environment.
The only strange part of the environment variable registration process occurs
when an environment variable is used for the Output or
Intermediate directory. Even though Auto Build Environment reconfigures
the environment per solution configuration at build time, the Output and
Intermediate directories are resolved by Visual Studio .NET once at
solution open time. Auto Build Environment compensates for that by reading
the .slnenv file at solution open time, too.
Applying the .slnenv file at solution open time also has benefit when
modifying a setting such as the
PATH The new
will be available through the entire session, including when the solution is
I hope the Auto Build Environment add-in will be useful to you. If
you have comments or find a bugs, please report them here or via email at
Author, Auto Build Environment Add-in
21 Nov 2002 - Initial Editing
Joshua Jensen is a gamer at heart and as such, creates games for a living. He has the distinct pleasure of creating titles exclusively for the Xbox.
In his spare time, he maintains a Visual C++ add-in called Workspace Whiz! Find it at http://workspacewhiz.com/.