0 out of 2 rated this helpful - Rate this topic

How to: Use Environment Variables in a Build

When you build projects, it is often necessary to set build options using information that is not in the project file or the files that comprise your project. This information is typically stored in environment variables.

All environment variables are available to the Microsoft Build Engine (MSBuild) project file as properties.

Note Note

If the project file contains an explicit definition of a property that has the same name as an environment variable, the property in the project file overrides the value of the environment variable.

To use an environment variable in an MSBuild project

  • Reference the environment variable the same way you would a variable declared in your project file. For example, the following code references the BIN_PATH environment variable:

    <FinalOutput>$(BIN_PATH)\MyAssembly.dll</FinalOutput>

You can use a Condition attribute to provide a default value for a property if the environment variable was not set.

To provide a default value for a property

  • Use a Condition attribute on a property to set the value only if the property has no value. For example, the following code sets the ToolsPath property to c:\tools only if the ToolsPath environment variable is not set:

    <ToolsPath Condition="'$(TOOLSPATH)' == ''">c:\tools</ToolsPath>

    Note Note

    Property names are not case-sensitive so both $(ToolsPath) and $(TOOLSPATH) reference the same property or environment variable.

The following project file uses environment variables to specify the location of directories.

<Project DefaultTargets="FakeBuild">
    <PropertyGroup>
        <FinalOutput>$(BIN_PATH)\myassembly.dll</FinalOutput>
        <ToolsPath Condition=" '$(ToolsPath)' == '' ">
            C:\Tools
        </ToolsPath>
    </PropertyGroup>
    <Target Name="FakeBuild">
        <Message Text="Building $(FinalOutput) using the tools at $(ToolsPath)..."/>
    </Target>
</Project>
Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Environment Variable Caching
Visual Studio 2010 has changed how environment variables are handled.  VS2k10 now aggressively caches environment variables, apparently for a specific period of time (1 day?).  This will persist even through reboots.
Environment variables are not "live"
MSBuild only reads environment variables in when it initializes the property collection, which in the general case is at some undermined time before you do any evaluating or building. After that they are static: each project starts with the same names and values.

To get environment variables live, use the property functions, see GetEnvironmentVariable inhttp://msdn.microsoft.com/en-us/library/dd633440.aspx However instead generally to manipulate scalars in the build you should set and get standard MSBuild properties. Even when a tool your build spawns needs environment variables, it should not be necessary to set or get them "live", as all tasks that spawn tools have a parameter available to you called EnvironmentVariables. (http://msdn.microsoft.com/en-us/library/microsoft.build.utilities.tooltask.environmentvariables.aspx) When you pass values to this, MSbuild sets them as environment variables only on the spawned tool, not its own process. One of the few examples I can think of where you might want to read or write a live environment variable is where an inproc task sets or gets them and you can't fix the task to use properties.

Each MSBuild project has an isolated environment block: it only sees reads and writes to its own block.

Note that not all environment variables are read in to become initial properties - any whose names aren't valid MSBuild property names, such as "386", are ignored.
Advertisement