Help
How Custom MSBuild Properties Work
Team Build enables passing MSBuild command-line options using the Queue Build dialog. In order for that to work, the build should be queued by someone that has the 'Administer a Build' security privilege. MSBuild command-line can consist of properties (/p:p1=v1;p2=v2;...), targets (/t:t1;t2;...), loggers (/l:mylogger), or other MSBuild options (e.g. verbosity: /v:diag).
The TFS Checkin Validation Tools enables passing a pre-defined set of custom MSBuild properties. This can be defined and controlled by the Buddy Build Integration Web Service.
The Buddy Build Integration Web Service acts as a proxy between the TFS Checkin Validation Tool VS2008 Add-in and TFS 2008. It allows TFS users that do not have the 'Administer a Build' privilege to be able to utilize buddy build and gated check-ins through impersonating a build account.
The Buddy Build Integration Web Service enables defining a set of custom properties that are allowed to be passed to Team Build. These are typically a set of properties that your build script might use. For example, your Team Build script might expect a property called IsDeploy, and it might evaluate it in the build script to see if it is true (e.g. '$(IsDeploy)'=='True'), and based on that it would deploy a build and run some build verification tests (BVT) against it. This feature allows a build administrator to define a set of custom MSBuild properties that are acceptable to be passed by ordinary developers while queuing buddy builds, gated check-ins, or even regular builds queued using the TFS Checkin Validation Tool. This way, Team Build's security model is not compromised by allowing any MSBuild command-line options since the Buddy Build Integration Web Service limits the command-line options to MSBuild properties, and only those properties that are defined in a special XML file stored under the web service and called CustomMsBuildProperties.xml.
Defining Custom MSBuild Properties
To define your own set of custom MSBuild properties, after you've installed the Buddy Build Integration Web Service, navigate to the installation location and open the CustomMsBuildProperties.xml file found under the App_Data folder in any text editor.

The following is an example of some custom properties defined:
<?xml
version="1.0"
encoding="utf-8"
?>
<!--
e.g.:
<TfsHosts
xmlns="http://schemas.microsoft.com/developer/buddybuildwebservice/2009/customproperties">
<Host
Name="DefaultSettings">
<TeamProject Name="DefaultSettings">
<BuildDefinition Name="DefaultSettings">
<Properties>
<Property>
<Name>IsDeploy</Name>
<DefaultValue>True</DefaultValue>
<Description>Set to true to indicate that this build is to be
deployed after building.</Description>
<PropertyDataType>System.Boolean</PropertyDataType>
</Property>
</Properties>
</BuildDefinition>
</TeamProject>
</Host>
</TfsHosts>
-->
<TfsHosts
xmlns="http://schemas.microsoft.com/developer/buddybuildwebservice/2009/customproperties">
<Host
Name="DefaultSettings">
<TeamProject
Name="DefaultSettings">
<BuildDefinition
Name="DefaultSettings">
<Properties>
<Property>
<Name>IsDeploy</Name>
<DefaultValue>True</DefaultValue>
<Description>Set to true to indicate
that this build is to be deployed after building the sources.</Description>
<PropertyDataType>System.Boolean</PropertyDataType>
</Property>
<Property>
<Name>IsTest</Name>
<DefaultValue>False</DefaultValue>
<Description>Set to true to indicate
that this build is to be tested after building the sources.</Description>
<PropertyDataType>System.Boolean</PropertyDataType>
</Property>
<Property>
<Name>DemoMode</Name>
<DefaultValue>False</DefaultValue>
<Description>Set to true to signify
demo mode.</Description>
<PropertyDataType>System.Boolean</PropertyDataType>
</Property>
<Property>
<Name>BuildPrefixName</Name>
<DefaultValue>SuperBuild_</DefaultValue>
<Description>Set to the string to be
used as the prefix in naming builds.</Description>
<PropertyDataType>System.String</PropertyDataType>
</Property>
<Property>
<Name>BuildAccount</Name>
<DefaultValue>REDMOND\ddedlab</DefaultValue>
<Description>The domain account under
which to run the build.</Description>
<PropertyDataType>System.String</PropertyDataType>
</Property>
<Property>
<Name>NoValueFiller</Name>
<DefaultValue>(Unassigned)</DefaultValue>
<Description>Set to the string to be
used as the filler when no value is specified.</Description>
<PropertyDataType>System.String</PropertyDataType>
</Property>
</Properties>
</BuildDefinition>
</TeamProject>
</Host>
You can download this sample CustomMSBuildProperties.xml from here.
Note that the property can be any of the standard data types. You should use the full .NET data type name when specifying the data type for a property. For example, use System.String for string data types, System.Int32 for 32-bit integers, and so forth.
You can verify them by launching the 'Queue Buddy Build Scheduler' dialog from a VS2008 client. For the above properties, the dialog would look something like the following:

To override the property values, you can either edit them directly in the 'Additional Properties' textbox, or use the Properties Editor grid by clicking on the 'Edit Properties…' button. You will be presented with a dialog asking if you would like to override the grid with the properties found on the textbox. Choose yes if you have made changes to the property values in the textbox and would like to have them carried over to the properties grid.

The properties grid allows you to edit the property value. It will validate the property value according to the property datatype. In order to restore the default values from the web service, you can click the 'Restore Default Properties…' button:

Custom MSBuild properties can be useful if you have build scripts that would change behavior based on any MSBuild properties that you pass to them with certain values. In the example above, the IsDeploy property instructs the build script that the build should be deployed after the build succeeds, but tests should not be run (IsTest is false). In your build script, you would be referencing IsDeploy as $(IsDeploy).