Introduction

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.

Background

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:

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.

Example

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
as Game.sln.

-- Provide a reasonable default.
DXPATH=c:\dxsdk
-- Call the user .slnenv file so it can override.
-- We don't use forceinclude so this is optional.
include $(HOMEDRIVE)$(HOMEPATH)\UserDXPath
-- Now, build the compile options.
COMPILE_OPTS=/I "$(DXPATH)\Include"

The UserDXPath.slnenv file may look like this:

-- The DirectX SDK is actually at the d:\Program Files\DXSDK directory.
DXPATH=d:\Program Files\DXSDK

When the Game.sln file is run, the environment variable

DXPATH

is available to it via $(DXPATH) and

COMPILE_OPTS

is available via $(COMPILE_OPTS). If
$(COMPILE_OPTS) is inserted into the Command-Line Options property
page, the build uses your DirectX directory.

Technical Details

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
DllRegisterServer() and DllUnregisterServer() that
install and uninstall the add-in registry entries without additional install
scripts.

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 SetEnvironmentVariable()
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 PATH
will be available through the entire session, including when the solution is
run.

Known Bugs

None at this time.

Conclusion

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
'jjensen@workspacewhiz.com'.

Edit History

21 Nov 2002 - Initial Editing

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Comments and Discussions

I have only one idea. Probably, VS 2010 create new thread for build project and "build thread" doesn't inherit environment. So it is impossible to increase environment by calling method SetEnvironmentVariable from parent thread of _dispBuildEvents Interface .

I tried another approach. I got it to compile and load correctly by just changing the registry to register for Version 9.0 in Connect.cpp, and handling version == "9.0" whereever version == "8.0" was checked.

This works, but only some functionality works. Most notably, the functionality to reload the slnenv when builds are made does not seem to work for me.

Thanks for posting that! I downloaded the code from svn last night to try and fix this myself, but it appears that code is also out of date.

In any event, this version of the addin looks to work very well. FWIW, I am using it to set the deployment root for a game project. The deployment root is set in the vcproj rather than the suo so we can't have user customized targets. With this addin, we can make the setting via an environment variable and then have user customized slnenv files. It perfectly solves the problem.

After installing ServicePack 1 for Visual Studio 2005 .NET this add in no longer works when opening a solution via the command line interface to Visual Studio (i.e. devenv.exe )
Has anybody else experienced this and maybe even fixed it.

When I try to open the projet message I got this error :
The project file "D:\Documents and Settings\gbarry\Mes Doucments\Visual Studio 2005\Projects\WindowsApplication1\$(TEST)\WindowsApplication1.vbproj" has moved, renamed or is not on your computer.

Sadly, all I really know about this is an experience with a C# user. In C#, macro expansion doesn't seem to happen with environment variables. We tried everything we could think of. This was in VS2003, but it wouldn't surprise me if it hasn't changed.

Mr. Josh:
Your build environment add-in helps us very much, we run it very well till today one problem happened, after debuging and test, we found, the size of .slnenv file could not be greater than 14k, otherwise, if we want to run a program without debugging(ctrl + F5), the devenv will report:
"Unable to start debugging.
Unable to start program 'C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\vcspawn.exe"
But "F5" is working still.

I guess the size is not the problem, maybe the number of environment is the real problem, for that we have set more than 200 environment variables and the average length of value of each variables is around 1K.

We have tested if we delete some environment variables, the problem disappears, by checking, the file is less than 14k, and number of variable is around 140.