1. What's New in MSBuild 12.0
MSBuild is now installed as part of Visual Studio rather than as part of the .NET Framework. The current MSBuild version number is 12.0. If you want to install MSBuild separately, download the installation package from MSBuild Download.
Changed Path
MSBuild is now installed directly under %ProgramFiles%—for example, in C:\Program Files\MSBuild\.
Changed Properties
The following MSBuild properties are changed as a result of the new version number: * MSBuildToolsVersion for this version of tools is 12.0. * MSBuildToolsPath is now %ProgramFiles%\MSBuild\12.0\bin on 32-bit operating systems, or %ProgramFiles%\MSBuild\12.0\bin\amd64 on 64-bit operating systems. * ToolsVersion values can be found in HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0 for 32-bit operating systems or HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\12.0 for 64-bit operating systems. * The SDK35ToolsPath and SDK40ToolsPath properties point to the .NET Framework SDK that's packaged with this version of Visual Studio (for example, 8.1A for the 4.X tools).
New Properties * MSBuildFrameworkToolsPath is a new property that has a value of %windir%\Microsoft.NET\Framework\v4.0.30319 on 32-bit operating systems or %windir%\Microsoft.NET\Framework64\v4.0.30319 on 64-bit operating systems. This is a replacement for MSBuildToolsPath that can be used to point to the .NET Framework tools and utilities. * MSBuildToolsPath and MSBuildFrameworkToolsPath have 32-bit equivalents—MSBuildToolsPath32 and MSBuildFrameworkToolsPath32—that always point to the 32-bit location, regardless of whether 32-bit or 64-bit MSBuild is being used.

2. MSBuild Concepts
MSBuild provides a basic XML schema that you can use to control how the build platform builds software. To specify the components in the build and how they are to be built, use these four parts of MSBuild: properties, items, tasks, and targets.
Related Topics Title | Description | MSBuild Properties | Introduces properties and property collections. Properties are key/value pairs that you can use to configure builds. | MSBuild Items | Describes the general concepts behind the MSBuild file format and how the pieces fit together. | MSBuild Targets | Explains how to group tasks together in a particular order and enable sections of the build process to be called on the command line. | MSBuild Tasks | Shows how to create a unit of executable code that can be used by MSBuild to perform atomic build operations. | Comparing Properties and Items | Compares MSBuild properties and items. Both are used to pass information to tasks, evaluate conditions, and store values that can be referenced throughout the project file. | MSBuild Special Characters | Explains how to escape some characters that MSBuild reserves for special use in specific contexts. | Walkthrough: Creating an MSBuild Project File from Scratch | Shows how to create a basic project file incrementally, by using only a text editor. | Walkthrough: Using MSBuild | Introduces the building blocks of MSBuild and shows how to write, manipulate, and debug MSBuild projects without closing the Visual Studio integrated development environment (IDE). | MSBuild Reference | Links to documents that contain reference information. | MSBuild | Presents an overview of the XML schema for a project file and shows how it controls processes that builds software. |

3.1. MSBuild Properties
Properties are name-value pairs that can be used to configure builds. Properties are useful for passing values to tasks, evaluating conditions, and storing values that will be referenced throughout the project file.
Defining and Referencing Properties in a Project File
Properties are declared by creating an element that has the name of the property as a child of a PropertyGroup element. For example, the following XML creates a property named BuildDir that has a value of Build.
Copy
<PropertyGroup> <BuildDir>Build</BuildDir> </PropertyGroup>
Throughout the project file, properties are referenced by using the syntax $(PropertyName). For example, the property in the previous example is referenced by using $(BuildDir).
Property values can be changed by redefining the property. The BuildDir property can be given a new value by using this XML:
Copy
<PropertyGroup> <BuildDir>Alternate</BuildDir> </PropertyGroup>
Properties are evaluated in the order in which they appear in the project file. The new value for BuildDir must be declared after the old value is assigned.
Reserved Properties
MSBuild reserves some property names to store information about the project file and the MSBuild binaries. These properties are referenced by using the $ notation, just like any other property. For example, $(MSBuildProjectFile) returns the complete file name of the project file, including the file name extension.
For more information, see How to: Reference the Name or Location of the Project File and MSBuild Reserved and Well-Known Properties.
Environment Properties
You can reference environment variables in project files just as you reference reserved properties. For example, to use the PATH environment variable in your project file, use $(Path). If the project contains a property definition that has the same name as an environment property, the property in the project overrides the value of the environment variable.
Each MSBuild project has an isolated environment block: it only sees reads and writes to its own block. MSBuild only reads environment variables when it initializes the property collection, before the project file is evaluated or built. After that, environment properties are static, that is, each spawned tool starts with the same names and values.
To get the current value of environment variables from within a spawned tool, use the Property Functions System.Environment.GetEnvironmentVariable. The preferred method, however, is to use the task parameter EnvironmentVariables. Environment properties set in this string array can be passed to the spawned tool without affecting the system environment variables. Tip | Not all environment variables are read in to become initial properties. Any environment variable whose name is not a valid MSBuild property names, such as "386", is ignored. |
For more information, see How to: Use Environment Variables in a Build.
Registry Properties
You can read system registry values by using the following syntax, where Hive is the registry hive (for example, HKEY_LOCAL_MACHINE ), Key is the key name, SubKey is the subkey name, and Value is the value of the subkey.
Copy
$(registry:Hive\MyKey\MySubKey@Value)
To get the default subkey value, omit the Value.
Copy
$(registry:Hive\MyKey\MySubKey)
This registry value can be used to initialize a build property. For example, to create a build property that represents the Visual Studio web browser home page, use this code:
Copy
<PropertyGroup> <VisualStudioWebBrowserHomePage> $(registry:HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\WebBrowser@HomePage) </VisualStudioWebBrowserHomePage> <PropertyGroup>
Global Properties
MSBuild lets you set properties on the command line by using the /property (or /p) switch. These global property values override property values that are set in the project file. This includes environment properties, but does not include reserved properties, which cannot be changed.
The following example sets the global Configuration property to DEBUG.
Copy
msbuild.exe MyProj.proj /p:Configuration=DEBUG
Global properties can also be set or modified for child projects in a multi-project build by using the Properties attribute of the MSBuild task. For more information, see MSBuild Task.
If you specify a property by using the TreatAsLocalProperty attribute in a project tag, that global property value doesn't override the property value that's set in the project file. For more information, see Project Element (MSBuild) and How to: Build the Same Source Files with Different Options.
Property Functions
Starting in .NET Framework version 4, you can use property functions to evaluate your MSBuild scripts. You can read the system time, compare strings, match regular expressions, and perform many other actions within your build script without using MSBuild tasks.
You can use string (instance) methods to operate on any property value, and you can call the static methods of many system classes. For example, you can set a build property to today's date as follows.
Copy
<Today>$([System.DateTime]::Now.ToString("yyyy.MM.dd"))</Today>
For more information, and a list of property functions, see Property Functions.
Creating Properties During Execution
Properties positioned outside Target elements are assigned values during the evaluation phase of a build. During the subsequent execution phase, properties can be created or modified as follows: * A property can be emitted by any task. To emit a property, the Task element must have a child Output element that has a PropertyName attribute. * A property can be emitted by the CreateProperty task. This usage is deprecated. * Starting in the .NET Framework 3.5, Target elements may contain PropertyGroup elements that may contain property declarations.
Storing XML in Properties
Properties can contain arbitrary XML, which can help in passing values to tasks or displaying logging information. The following example shows the ConfigTemplate property, which has a value that contains XML and other property references. MSBuild replaces the property references by using their respective property values. Property values are assigned in the order in which they appear. Therefore, in this example, $(MySupportedVersion), $(MyRequiredVersion), and $(MySafeMode) should have already been defined.
Copy
<PropertyGroup> <ConfigTemplate> <Configuration> <Startup> <SupportedRuntime ImageVersion="$(MySupportedVersion)" Version="$(MySupportedVersion)"/> <RequiredRuntime ImageVersion="$(MyRequiredVersion) Version="$(MyRequiredVersion)" SafeMode="$(MySafeMode)"/> </Startup> </Configuration> </ConfigTemplate> </PropertyGroup>

3.2.1. 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.
Referencing Environment Variables
All environment variables are available to the Microsoft Build Engine (MSBuild) project file as properties. 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 | Property names are not case-sensitive so both $(ToolsPath) and $(TOOLSPATH) reference the same property or environment variable. |
Example
The following project file uses environment variables to specify the location of directories.
Copy
<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>

3.2.2. How to: Reference the Name or Location of the Project File
You can use the name or location of the project in the project file itself without having to create your own property. MSBuild provides reserved properties that reference the project file name and other properties related to the project. For more information on reserved properties, see MSBuild Reserved and Well-Known Properties.
Using the MSBuildProjectName Property
MSBuild provides some reserved properties that you can use in your project files without defining them each time. For example, the reserved property MSBuildProjectName provides a reference to the project file name.
To use the MSBuildProjectName Property * Reference the property in the project file with the $() notation, just as you would with any property. For example:
Copy
<CSC Sources = "@(CSFile)" OutputAssembly = "$(MSBuildProjectName).exe"/>
</CSC>
An advantage of using a reserved property is that any changes to the project file name are incorporated automatically. The next time that you build the project, the output file will have the new name with no further action required on your part. Note | Reserved properties cannot be redefined in the project file. |
Example
The following example project file references the project name as a reserved property to specify the name for the output.
Copy
<Project xmlns="http://scheams.microsoft.com/developer/msbuild/2003" DefaultTargets = "Compile">

<!-- Specify the inputs --> <ItemGroup> <CSFile Include = "consolehwcs1.cs"/> </ItemGroup> <Target Name = "Compile"> <!-- Run the Visual C# compilation using input files of type CSFile --> <CSC Sources = "@(CSFile)" OutputAssembly = "$(MSBuildProjectName).exe" > <!-- Set the OutputAssembly attribute of the CSC task to the name of the project --> <Output TaskParameter = "OutputAssembly" ItemName = "EXEFile" /> </CSC> <!-- Log the file name of the output file --> <Message Text="The output file is @(EXEFile)"/> </Target>
</Project>

3.2.3. How to: Build the Same Source Files with Different Options
When you build projects, you frequently compile the same components with different build options. For example, you can create a debug build with symbol information or a release build with no symbol information but with optimizations enabled. Or you can build a project to run on a specific platform, such as x86 or x64. In all these cases, most of the build options stay the same; only a few options are changed to control the build configuration. With MSBuild, you use properties and conditions to create the different build configurations.
Using Properties to Modify Projects
The Property element defines a variable that is referenced several times in a project file, such as the location of a temporary directory, or to set the values for properties that are used in several configurations, such as a Debug build and a Release build. For more information about properties, see MSBuild Properties.
You can use properties to change the configuration of your build without having to change the project file. The Condition attribute of the Property element and the PropertyGroup element allows you to change the value of properties. For more information about MSBuild conditions, see MSBuild Conditions.
To set a group of properties based on another property * Use a Condition attribute in a PropertyGroup element similar to the following:
Copy
<PropertyGroup Condition="'$(Flavor)'=='DEBUG'"> <DebugType>full</DebugType> <Optimize>no</Optimize>
</PropertyGroup>
To define a property based on another property * Use a Condition attribute in a Property element similar to the following:
Copy
<DebugType Condition="'$(Flavor)'=='DEBUG'">full</DebugType>
Specifying Properties on the Command Line
Once your project file is written to accept multiple configurations, you need to have the ability to change those configurations whenever you build your project. MSBuild provides this ability by allowing properties to be specified on the command line using the /property or /p switch.
To set a project property at the command line * Use the /property switch with the property and property value. For example:
Copy
msbuild file.proj /property:Flavor=Debug
- or -
Copy
Msbuild file.proj /p:Flavor=Debug
To specify more than one project property at the command line * Use the /property or /p switch multiple times with the property and property values, or use one /property or /p switch and separate multiple properties with semicolons (;). For example:
Copy
msbuild file.proj /p:Flavor=Debug;Platform=x86
- or-
Copy
msbuild file.proj /p:Flavor=Debug /p:Platform=x86
Environment variables are also treated as properties and are automatically incorporated by MSBuild. For more information about using environment variables, see How to: Use Environment Variables in a Build.
The property value that is specified on the command line takes precedence over any value that is set for the same property in the project file, and that value in the project file takes precedence over the value in an environment variable.
You can change this behavior by using the TreatAsLocalProperty attribute in a project tag. For property names that are listed with that attribute, the property value that's specified on the command line doesn't take precedence over the value in the project file. You can find an example later in this topic.
Example
The following code example, the "Hello World" project, contains two new property groups that can be used to create a Debug build and a Release build.
To build the debug version of this project, type:
Copy
msbuild consolehwcs1.proj /p:flavor=debug
To build the retail version of this project, type:
Copy
msbuild consolehwcs1.proj /p:flavor=retail
Copy
<Project DefaultTargets = "Compile" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<!-- Sets the default flavor of an environment variable called Flavor is not set or specified on the command line --> <PropertyGroup> <Flavor Condition="'$(Flavor)'==''">DEBUG</Flavor> </PropertyGroup>

<!-- Define the DEBUG settings --> <PropertyGroup Condition="'$(Flavor)'=='DEBUG'"> <DebugType>full</DebugType> <Optimize>no</Optimize> </PropertyGroup>

<!-- Define the RETAIL settings --> <PropertyGroup Condition="'$(Flavor)'=='RETAIL'"> <DebugType>pdbonly</DebugType> <Optimize>yes</Optimize> </PropertyGroup>

<!-- Set the application name as a property --> <PropertyGroup> <appname>HelloWorldCS</appname> </PropertyGroup>

<!-- Specify the inputs by type and file name --> <ItemGroup> <CSFile Include = "consolehwcs1.cs"/> </ItemGroup>

<Target Name = "Compile"> <!-- Run the Visual C# compilation using input files of type CSFile --> <CSC Sources = "@(CSFile)" DebugType="$(DebugType)" Optimize="$(Optimize)" OutputAssembly="$(appname).exe" >

<!-- Set the OutputAssembly attribute of the CSC task to the name of the executable file that is created --> <Output TaskParameter="OutputAssembly" ItemName = "EXEFile" /> </CSC> <!-- Log the file name of the output file --> <Message Text="The output file is @(EXEFile)"/> </Target>
</Project>
The following example illustrates how to use the TreatAsLocalProperty attribute. The Color property has a value of Blue in the project file and Green in the command line. With TreatAsLocalProperty="Color" in the project tag, the command-line property (Green) doesn't override the property that's defined in the project file (Blue).
To build the project, enter the following command:
Copy
msbuild colortest.proj /t:go /property:Color=Green
Copy
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
ToolsVersion="4.0" TreatAsLocalProperty="Color">

<PropertyGroup> <Color>Blue</Color> </PropertyGroup>

<Target Name="go"> <Message Text="Color: $(Color)" /> </Target>
</Project>

<!-- Output with TreatAsLocalProperty="Color" in project tag: Color: Blue

Output without TreatAsLocalProperty="Color" in project tag: Color: Green
-->

3.2.4. Property Functions
In the .NET Framework versions 4 and 4.5, property functions can be used to evaluate MSBuild scripts. Property functions can be used wherever properties appear. Unlike tasks, property functions can be used outside of targets, and are evaluated before any target runs.
Without using MSBuild tasks, you can read the system time, compare strings, match regular expressions, and perform other actions in your build script. MSBuild will try to convert string to number and number to string, and make other conversions as required.
In this topic: * Property Function Syntax * String Property Functions * Static Property Functions * Calling Instance Methods on Static Properties * MSBuild Property Functions * Nested Property Functions * MSBuild DoesTaskHostExist * MSBuild GetDirectoryNameOfFileAbove * MSBuild GetRegistryValue * MSBuild GetRegistryValueFromView * MSBuild MakeRelative * MSBuild ValueOrDefault
Property Function Syntax
These are three kinds of property functions; each function has a different syntax: * String (instance) property functions * Static property functions * MSBuild property functions
String Property Functions
All build property values are just string values. You can use string (instance) methods to operate on any property value. For example, you can extract the drive name (the first three characters) from a build property that represents a full path by using this code:
$(ProjectOutputFolder.Substring(0,3))
Static Property Functions
In your build script, you can access the static properties and methods of many system classes. To get the value of a static property, use the following syntax, where Class is the name of the system class and Property is the name of the property.
$([Class]::Property)
For example, you can use the following code to set a build property to the current date and time.
<Today>$([System.DateTime]::Now)</Today>
To call a static method, use the following syntax, where Class is the name of the system class, Method is the name of the method, and (Parameters) is the parameter list for the method:
$([Class]::Method(Parameters))
For example, to set a build property to a new GUID, you can use this script:
<NewGuid>$([System.Guid]::NewGuid())</NewGuid>
In static property functions, you can use any static method or property of these system classes: * System.Byte * System.Char * System.Convert * System.DateTime * System.Decimal * System.Double * System.Enum * System.Guid * System.Int16 * System.Int32 * System.Int64 * System.IO.Path * System.Math * System.UInt16 * System.UInt32 * System.UInt64 * System.SByte * System.Single * System.String * System.StringComparer * System.TimeSpan * System.Text.RegularExpressions.Regex * Microsoft.Build.Utilities.ToolLocationHelper
In addition, you can use the following static methods and properties: * System.Environment::CommandLine * System.Environment::ExpandEnvironmentVariables * System.Environment::GetEnvironmentVariable * System.Environment::GetEnvironmentVariables * System.Environment::GetFolderPath * System.Environment::GetLogicalDrives * System.IO.Directory::GetDirectories * System.IO.Directory::GetFiles * System.IO.Directory::GetLastAccessTime * System.IO.Directory::GetLastWriteTime * System.IO.Directory::GetParent * System.IO.File::Exists * System.IO.File::GetCreationTime * System.IO.File::GetAttributes * System.IO.File::GetLastAccessTime * System.IO.File::GetLastWriteTime * System.IO.File::ReadAllText
Calling Instance Methods on Static Properties
If you access a static property that returns an object instance, you can invoke the instance methods of that object. To invoke an instance method, use the following syntax, where Class is the name of the system class, Property is the name of the property, Method is the name of the method, and (Parameters) is the parameter list for the method:
$([Class]::Property.Method(Parameters))
The name of the class must be fully qualified with the namespace.
For example, you can use the following code to set a build property to the current date today.
<Today>$([System.DateTime]::Now.ToString("yyyy.MM.dd"))</Today>
MSBuild Property Functions
Several static methods in your build can be accessed to provide arithmetic, bitwise logical, and escape character support. You access these methods by using the following syntax, where Method is the name of the method and Parameters is the parameter list for the method.
$([MSBuild]::Method(Parameters))
For example, to add together two properties that have numeric values, use the following code.
$([MSBuild]::Add($(NumberOne), $(NumberTwo))
Here is a list of MSBuild property functions: Function Signature | Description | double Add(double a, double b) | Add two doubles. | long Add(long a, long b) | Add two longs. | double Subtract(double a, double b) | Subtract two doubles. | long Subtract(long a, long b) | Subtract two longs. | double Multiply(double a, double b) | Multiply two doubles. | long Multiply(long a, long b) | Multiply two longs. | double Divide(double a, double b) | Divide two doubles. | long Divide(long a, long b) | Divide two longs. | double Modulo(double a, double b) | Modulo two doubles. | long Modulo(long a, long b) | Modulo two longs. | string Escape(string unescaped) | Escape the string according to MSBuild escaping rules. | string Unescape(string escaped) | Unescape the string according to MSBuild escaping rules. | int BitwiseOr(int first, int second) | Perform a bitwise OR on the first and second (first | second). | int BitwiseAnd(int first, int second) | Perform a bitwise AND on the first and second (first & second). | int BitwiseXor(int first, int second) | Perform a bitwise XOR on the first and second (first ^ second). | int BitwiseNot(int first) | Perform a bitwise NOT (~first). |
Nested Property Functions
You can combine property functions to form more complex functions, as the following example shows.
$([MSBuild]::BitwiseAnd(32, $([System.IO.File]::GetAttributes(tempFile))))
This example returns the value of the FileAttributes Archive bit (32 or 0) of the file given by the path tempFile. Notice that enumerated data values cannot appear by name within property functions. The numeric value (32) must be used instead.
Metadata may also appear in nested property functions. For more information, see MSBuild Batching.
MSBuild DoesTaskHostExist
The DoesTaskHostExist property function in MSBuild returns whether a task host is currently installed for the specified runtime and architecture values.
This property function has the following syntax:
Copy
$[MSBuild]::DoesTaskHostExist(string theRuntime, string theArchitecture)
MSBuild GetDirectoryNameOfFileAbove
The MSBuild GetDirectoryNameOfFileAbove property function looks for a file in the directories about the current directory in the path.
This property function has the following syntax:
Copy
$[MSBuild]::GetDirectoryNameOfFileAbove(string ThePath, string TheFile)
The following code is an example of this syntax.
Copy
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), EnlistmentInfo.props))\EnlistmentInfo.props" Condition=" '$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), EnlistmentInfo.props))' != '' " />
MSBuild GetRegistryValue
The MSBuild GetRegistryValue property function returns the value of a registry key. This function takes two arguments, the key name and the value name, and returns the value from the registry. If you don't specify a value name, the default value is returned.
The following examples show how this function is used:
Copy
$([MSBuild]::GetRegistryValue(`HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Debugger`, ``)) // default value
$([MSBuild]::GetRegistryValue(`HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Debugger`, `SymbolCacheDir`))
$([MSBuild]::GetRegistryValue(`HKEY_LOCAL_MACHINE\SOFTWARE\(SampleName)`, `(SampleValue)`)) // parens in name and value
MSBuild GetRegistryValueFromView
The MSBuild GetRegistryValueFromView property function gets system registry data given the registry key, value, and one or more ordered registry views. The key and value are searched in each registry view in order until they are found.
The syntax for this property function is:
[MSBuild]::GetRegistryValueFromView(string keyName, string valueName, object defaultValue, params object[] views)
The Windows 64-bit operating system maintains a HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node registry key that presents a HKEY_LOCAL_MACHINE\SOFTWARE registry view for 32-bit applications.
By default, a 32-bit application running on WOW64 accesses the 32-bit registry view and a 64-bit application accesses the 64-bit registry view.
The following registry views are available: Registry View | Definition | RegistryView.Registry32 | The 32-bit application registry view. | RegistryView.Registry64 | The 64-bit application registry view. | RegistryView.Default | The registry view that matches the process that the application is running on. |
The following is an example.
$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Silverlight\v3.0\ReferenceAssemblies', 'SLRuntimeInstallPath', null, RegistryView.Registry64, RegistryView.Registry32)) gets the SLRuntimeInstallPath data of the ReferenceAssemblies key, looking first in the 64-bit registry view and then in the 32-bit registry view.
MSBuild MakeRelative
The MSBuild MakeRelative property function returns the relative path of the second path relative to first path. Each path can be a file or folder.
This property function has the following syntax:
Copy
$[MSBuild]::MakeRelative($(FileOrFolderPath1), $(FileOrFolderPath2))
The following code is an example of this syntax.
Xml
Copy
<PropertyGroup>
<Path1>c:\users\</Path1> <Path2>c:\users\username\</Path2>
</PropertyGroup>

<Target Name = "Go"> <Message Text ="$([MSBuild]::MakeRelative($(Path1), $(Path2)))" /> <Message Text ="$([MSBuild]::MakeRelative($(Path2), $(Path1)))" />
</Target>

<!--
Output:
username\ ..\
-->
MSBuild ValueOrDefault
The MSBuild ValueOrDefault property function returns the first argument, unless it's null or empty. If the first argument is null or empty, the function returns the second argument.
The following example shows how this function is used.
Copy
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup> <Value1>$([MSBuild]::ValueOrDefault(`$(UndefinedValue)`, `a`))</Value1> <Value2>$([MSBuild]::ValueOrDefault(`b`, `$(Value1)`))</Value2> </PropertyGroup>

<Target Name="MyTarget"> <Message Text="Value1 = $(Value1)" /> <Message Text="Value2 = $(Value2)" /> </Target>
</Project>

<!--
Output:
Value1 = a Value2 = b
-->