TeamBuild 2008 Override(able) properties

I finally got tired of having to look these properties up and decided to place them in here (what makes looking on the web easier than looking in the actual file, I don't know, but maybe this will help somebody else as well).

Properties

MSTestRefPath - Path to Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll. Overridable so that the 8.0 version can be used for test assemblies compiled against the 8.0 unit test framework.

V8TestToolsTask - Set this property to true to use the 8.0 TestToolsTask.

IncrementalGet - Set this property to true to do an incremental get - this will override the CleanCompilationOutputOnly, SkipInitializeWorkspace, and ForceGet properties.

IncrementalBuild - Set this property to true to do an incremental build - this will override the SkipClean, SkipInitializeWorkspace, and ForceGet properties.

BuildProjectFolderPath - If BuildProjectFolderPath is not specified (typically in a Desktop build), assume local paths and set to MSBuildProjectDirectory.

SkipClean - Set this property to true to skip the CoreClean target.

SkipLabel - Set this property to true to skip the CoreLabel target.

SkipPostBuild - Set this property to true to skip the PostBuild target.

SkipGetChangesetsAndUpdateWorkItems - Set this property to skip the CoreGetChangesetsAndUpdateWorkItems target, which calls the GenCheckinNotesUpdateWorkItems task.

SkipDropBuild - Set this property to true to skip the CoreDropBuild target.

SkipWorkItemCreation - Set this property to true to skip the CoreCreateWorkItem target.

BuildConfigurationsInParallel - Set this property to true to enable building configurations in parallel.

BuildSolutionsInParallel - Set this property to true to enable building solutions in parallel.

SkipInvalidConfigurations - Set this property to false to generate an error when an invalid configuration is encountered.

StopOnFirstFailure - Set this property to true to stop Cleaning, Compiling, and/or Testing on the first failure encountered.

WorkspaceName - The name of the workspace that will be used for getting sources.
Note: Workspace name can be up to 64 characters long - after that it will be truncated.

CreateWorkspaceTaskComment - The comment used for workspace creation.

GetOverwrite - Set this value to true to enable overwriting of writable files without a force get.

RecursiveGet - Set this to false to do only a top-level get.

GetVersion - The VersionSpec to be used by the Get task.

GetFileSpec - The FileSpec to be used by the Get task. When empty, all top-level folders in the workspace are used.

GetPopulateOutput - Set this to true to populate the Gets, Replaces, and Deletes item group outputs of the Get task.

LabelRecursive - Set this to false to do only a top-level label.

LabelChild - Set this to Merge or Replace to control the treatment of unchanged items.

LabelComment - The comment used by the Label task.

LabelName - The label name used by the Label task. By default the label name is set to $(BuildNumber) in the InitializeEndToEndIteration target.

LabelFiles - The FileSpec to be used by the Label task Default:"$/".

LabelScope - The scope to be used by the Label task Default:"$/$(TeamProject).

VCBuildAdditionalLibPaths - The AdditionalLibPaths property of the VCBuild task used to compile VC++ projectstd.

VCBuildAdditionalOptions - The AdditionalOptions property of the VCBuild task used to compile VC++ projectstd.

VCBuildToolPath - The ToolPath property of the VCBuild task used to compile VC++ projects.

VCBuildUseEnvironment - The UseEnvironment property of the VCBuild task used to compile VC++ projects.

VCOverridesOpen - The beginning of the vsprops file used to override VCBuild properties.

VCOverridesClose - The end of the vsprops file used to override VCBuild properties.

UpdateAssociatedWorkItemsOnBuildBreak - Set this to true to update associated work items even on a build break.

CustomizableOutDir - Set this to true to allow OutDir customization.

CustomizablePublishDir - Set this to true to allow PublishDir customization.

OutDir - Set OutDir so that it is always available within TfsBuild.proj for backwards compatibility.

PublishDir - Set PublishDir so that it is always available within TfsBuild.proj for backwards compatibility.

TeamBuild 2008 - Passing properties to Solutions

Our build process requires that we label our builds according to the version that we are building, i.e. Assemblies will be stamped with 1.0.2.1 so the build label should be BuildDefinition_1.0.2.1-BuildCount. I won't detail the method to create the custom build number as that has already been done very nicely by Martin Woodward - you can see that here.

What hasn't been explained, for which I spent a few hours (okay days) trying to figure out was how to pass that version to our solutions.

Here's our process:
I created a custom build task that stored the version by build definition and incremented that version on each successful build (the script passes the build definition to the task, the task sets the output properties, if the last build was not successful, the version would not have been incremented instead the BuildCount would be incremented showing how many times that particular version was attempted). I then passed the output from the task to the SolutionToBuild list. The initial try left me with my default of 0.0.0.0 (discussion on whether that was right to default it to that can be held at another time). I thought my default property was overriding my output from the task. That was not the case. I finally found that the property was not being passed appropriately to the Item list.

I finally broke down and consulted the expert (at least the one I knew, Buck Hodges). Buck was kind enough to forward me on to Aaron Halberg who gave this reply:

"This is the last bug I fixed for SP1 – passing dynamically generated properties through to solutions/projects. Solving it is rather complicated, unfortunately.

I don’t think that his current workaround will do the trick, for example – he’s expecting the Version property to still be set when CoreCompileSolution is executed, and it won’t be, since he modified it in the global context and it wasn’t passed through to the recursive calls that result in CoreCompileSolution being executed.

He could override the CallCompile target to include the fix I added for SP1:

<Target Name="CallCompile"
DependsOnTargets="$(CoreCompileDependsOn)">

<PropertyGroup>
<OutDir Condition="'%(ConfigurationToBuild.PlatformToBuild)' !=
'Any CPU' ">
$(BinariesRoot)\%(ConfigurationToBuild.PlatformToBuild)\%(ConfigurationToBuild.FlavorToBuild)

</OutDir>

<OutDir Condition=" '%(ConfigurationToBuild.PlatformToBuild)' == 'Any CPU' ">$(BinariesRoot)\%(ConfigurationToBuild.FlavorToBuild)\

</OutDir>
</PropertyGroup>

<MSBuild Projects="$(MSBuildProjectFile)"
Properties="BuildAgentName=$(BuildAgentName); BuildAgentUri=$(BuildAgentUri); BuildDefinitionName=$(BuildDefinitionName); BuildDefinitionUri=$(BuildDefinitionUri); [... Removed for space ] TestResultsRoot=$(TestResultsRoot); $(CustomPropertiesForBuild)"
Targets="CoreCompile">
<output TaskParameter="TargetOutputs" ItemName="CompilationOutputs" />
<msbuild>

<OnError ExecuteTargets="SetBuildBreakProperties;OnBuildBreak;" />

</Target>

Then, after setting the version property in his BuildNumberOverrideTarget, he would do:

Version=$(Version);$(CustomPropertiesForBuild)

The only alternatives to that option that I can think of involve somehow storing the version property so that it can be set again in the appropriate context. For example, he could use the WriteLinesToFile task to write it out to a text file in the BuildNumberOverrideTarget and then do something like:<output taskparameter="Lines" itemname="VersionFileLines">

%(SolutionToBuild.Properties);Version=%(VersionFileLines.Identity)

…or:<output taskparameter="Lines" itemname="VersionFileLines">

Version=$(Version);$(CustomPropertiesForBuild)

The former adds the version property to the SolutionToBuild Properties metadata for each solution. The latter adds it to the CustomPropertiesForBuild property."

I followed the first option but both work well. Choose the one that best fits your style. I haven't seen this information on Aaron's or Buck's blog so I posted it here. If I see it in the near future I will post a link that direction.

Update: Here's Aaron's post: http://blogs.msdn.com/aaronhallberg/archive/2008/05/12/orcas-sp1-tfs-build-changes-part-2.aspx

Playing Know-It-All

I decided to finally update my trial version of VSTS 2008 to the released version (I was going from RC to RTM). What a pain! However, I did have plenty of time to visit some forums and update my blog.

I usually keep to myself and only answer questions when asked, but recently I have been trying to put myself "out there" and see if I can help others who find themselves in the same situation that I have been in. The only draw back is that you really never know how much help you were to the other party (unless of course they pile praises and acclamations galore stating such :). Secondly you have to overcome the inhibition that what you have to say may actually be of some importance to the other party (which can be a major challenge in and of itself).

Well, the upgrade is complete... and actually it was the uninstall of the RC bits that was the pain. The install of the RTM version was rather nice.