November 4, 2008
The Solution 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 Solution 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.
New versions of the Solution Build Environment add-in may be found on http://wwhiz.com/ in the Other Addins section.
Inside the SolutionName.slnenv file, with one entry per line, are
MYPATH=c:\Src\MyDirectory\Include EXTRA_OPTS=/D MY_DEFINE
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
A special form of assignment is available through the
operator. An assignment is only made if the environment variable does not
-- Only assign if PATH does not already exist. PATH ?= c:\windows
Some software packages don't handle relative paths very well. The Solution Build Environment add-in has a special symbol for expanding relative paths into an absolute form. The absolute expansion of the path is triggered by inserting an exclamation point at the beginning of the line.
RELPATH=c:\Windows\System32\.. !ABSPATH=$(RELPATH) # c:\Windows
Environment variables may be inserted using the
syntax. This has the same functionality as a batch file's
substitution syntax but more closely mirrors Visual Studio's syntax for
accessing environment variables.
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
-- This is a comment. // This is a comment. Key=Value # 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
file. First, we put a
Game.slnenv file in the same directory
-- 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"
UserDXPath.slnenv file may look like this:
-- The DirectX SDK is actually at the d:\Program Files\DXSDK directory. DXPATH=d:\Program Files\DXSDK
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.
Solution 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
devenv.exe. Builds launched from the IDE inherit the environment
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 Solution 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. Solution Build Environment compensates for that by reading
.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
Thanks to Carter L. Smithhart for the recent fixes to 1.10.
Copyright (C) 2000-2008 Joshua C. Jensen
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I hope the Solution 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 'email@example.com'.
Author, Solution Build Environment Add-in