Click here to Skip to main content
13,867,547 members
Click here to Skip to main content
Add your own
alternative version


26 bookmarked
Posted 20 Nov 2002

Auto Build Environment Add-in for Visual Studio .NET

, 20 Nov 2002
Rate this:
Please Sign up or sign in to vote.
Provides support for customized global environment build settings on a per solution basis
<!-- Download Links --> <!-- Add the rest of your HTML here -->


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 The VS.NET launching batch file is shown below:

rem StartVisualStudioNET.bat
set rp="\machine\software\Microsoft\VisualStudio\7.0\InstallDir"
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.

rem MyProject.bat
set MYPATH=%cd%\SomeDirectory
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 in the Misc. Code section.

Installation without the Installer

  1. Unzip the archive.
  2. Close down Visual Studio .NET.
  3. Run regsvr32 AutoBuildEnvironment.dll.
  4. 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 environmentvariablename=value entries.


The solution's path is available via a variable called $(SolutionDir). The solution directory does not contain a terminating backslash.


The solution's name is available through $(SolutionName).


Environment variables may be inserted using the $(EnvironmentVariableName) syntax. This has the same functionality as a batch file's %EnvironmentVariableName% substitution syntax.


Simple registry entries may be accessed via %(HKLM\Path\Key) or %(HKCU\Path\Key), where HKLM accesses

and HKCU accesses HKEY_CURRENT_USER. Only string values may be retrieved.


An environment variable may be applied onto a specific Solution Configuration. The syntax for this is ConfigurationName:Name=Value.


Other .slnenv files may be included using the

or forceinclude keywords. The filename following each keyword should not contain the .slnenv extension.

include $(HOMEDRIVE)$(HOMEPATH)\MyPersonalDefinitions<br>
forceinclude ..\..\MandatoryDefinitions

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

-- Provide a reasonable default.

-- 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.

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

is available to it via $(DXPATH) and
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

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.


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 ''.


Joshua Jensen
Author, Auto Build Environment Add-in

Edit History

21 Nov 2002 - Initial Editing


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.

A list of licenses authors might use can be found here


About the Author

Joshua Jensen
Web Developer
United States United States
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

You may also be interested in...


Comments and Discussions

GeneralVS 2010 Pin
FlamingWind_RUS25-Oct-10 3:21
memberFlamingWind_RUS25-Oct-10 3:21 
GeneralVS2008 Pin
Member 14483064-Nov-08 6:45
memberMember 14483064-Nov-08 6:45 
GeneralRe: VS2008 Pin
IainWildman18-Feb-09 6:57
memberIainWildman18-Feb-09 6:57 
GeneralRe: VS2008 Pin
jimmys79-Mar-09 21:28
memberjimmys79-Mar-09 21:28 
GeneralRe: VS2008 Pin
Joshua Jensen10-Mar-09 7:35
memberJoshua Jensen10-Mar-09 7:35 
GeneralRe: VS2008 Pin
jimmys710-Mar-09 10:39
memberjimmys710-Mar-09 10:39 
GeneralBroken with Visual Studio 2005 .NET Service Pack 1 Pin
mschuckmann12-Mar-07 12:54
membermschuckmann12-Mar-07 12:54 
GeneralRe: Broken with Visual Studio 2005 .NET Service Pack 1 Pin
Joshua Jensen12-Mar-07 13:08
memberJoshua Jensen12-Mar-07 13:08 
GeneralAdd-in not working for me Pin
gbarry16-Feb-07 3:05
membergbarry16-Feb-07 3:05 
GeneralRe: Add-in not working for me Pin
Joshua Jensen12-Mar-07 14:40
memberJoshua Jensen12-Mar-07 14:40 
Generaltroubleshooting Pin
siquan25-Oct-05 18:23
membersiquan25-Oct-05 18:23 
GeneralThis doesn't work at all Pin
wbott70130-Mar-05 11:39
memberwbott70130-Mar-05 11:39 
GeneralRe: This doesn't work at all Pin
Joshua Jensen30-Mar-05 16:56
memberJoshua Jensen30-Mar-05 16:56 
GeneralRe: This doesn't work at all Pin
Duan Zuoyi17-Aug-05 22:35
memberDuan Zuoyi17-Aug-05 22:35 
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.Cry | :((

Have you ever met this problem?

Thank you very much!Smile | :)

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web01 | 2.8.190214.1 | Last Updated 21 Nov 2002
Article Copyright 2002 by Joshua Jensen
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid