In previous blog post, we discussed about the concept of properties in MSBuild schema. We also saw few project files samples and about reserved properties. In this post, we are going to expand that knowledge by discussing how to use properties further.
Access Environment Variables
In some build configurations, when you build projects, it is often necessary to set build options using information that is not in the project file. This information is typically stored in environment variables. All environment variables are available to the MSBuild as properties. So we can simply access them in the same way we access properties i.e. by encapsulating their name in $(environmental_variable_name).
For example, below project file makes use of environmental variable named PATH:
Property names are not case sensitive, so PATH and Path would refer to the same property. Also, 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.
For example, in below project file sample, we have modified value of PATH variable:
If we run this configuration using MSBuild, we should see an output like below:
Do note that changing environmental variable value inside MSBuild by making use of property does not affect actual value of it with respect to environment itself.
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 new instance starts with the same names and values.
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:
This registry value can be used to initialize a build property.
Global Properties or Command Line Properties
You can also provide properties through the command line. For this you need to use the /property (or /p) switch to achieve this. When you use the /p switch, you must specify the values in the format /p:key=value, where key is the name of the property and value is its value. You can provide multiple values by separating the pairs by a semicolon or a comma.
The properties specified using this way become global properties and override property values that are set in the project file. This includes environment properties, but does not include reserved properties, which cannot be changed.
If we run below command to build this file, we should see something like below output:
msbuild /nologo understanding-msbuild-global-properties-01.proj /p:Configuration=Debug /p:OutputDir="C:\Source\Bin\\"
Note in this example that we passed the OutputDir contained in quotes and the end is marked with \ because \” is an escaped quote mark (“). In this case, the quotes are optional, but if you are passing values containing spaces, then they are required.
Also, it does not matter if the property is already defined somewhere in the project file or the location of property in the file. For example, consider below version of above project file:
MSBuild Output for above file:
Common MSBuild Project Properties
The following Microsoft table lists frequently used properties that are defined in the Visual Studio project files or included in .targets files that MSBuild provides.
Provide default value of a Property
We can 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 build configuration to Release only if the Configuration property is not set:
This way we can get flexibility to define Configuration property when running MSBuild or not.
In this blog post, we have learned how to make use of properties inside MSBuild schema to control build Configuration.