Thanks for the suggestions. I opted to write a set of custom targets to use with my MSBuild script which maintains assembly metadata in a remote xml "manifest" file. When a new TeamCity project is created, my build script calls an Init target which creates a new manifest file from an unpopulated template.
<Copy SourceFiles="@(ManifestTemplate)" DestinationFiles="@(ManifestTemplate->'$(ManifestFile)')" Condition="!Exists('$(ManifestFile)')" />
I'm using the MSBuild Extentions pack to read attributes like version information from the manifest file.
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="ReadElementText" File="$(ManifestFile)" XPath="/Package/Version/Major">
<Output PropertyName="PackageVersionMajor" TaskParameter="Value"/>
</MSBuild.ExtensionPack.Xml.XmlFile>
I have my TeamCity build configurations separated to CI, Test, Minor Release, and Major Release with different events triggering each. From the corresponding target in my project build script, I add a new target to DependsOnTargets
attribute to call the custom target to update the appropriate version number and save it to the manifest file.
<Target Name="Test" DependsOnTargets="IntializeBuildProject;Build-UpdateVersion-Build">
<MSBuild Projects="$(SolutionFile)" Targets="Rebuild" Properties="Configuration=$(Configuration)" />
<TeamCitySetBuildNumber BuildNumber="$(PackageVersion)" />
The code in the custom target to handle the version update:
<MSBuild.ExtensionPack.Science.Maths TaskAction="Add" Numbers="$(PackageVersionBuild);1">
<Output PropertyName="PackageVersionBuild" TaskParameter="Result"/>
</MSBuild.ExtensionPack.Science.Maths>
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="UpdateElement" File="$(ManifestFile)" XPath="/Package/Version/Build" InnerText="$(PackageVersionBuild)"/>
This file handles persistence of the version and other metadata thus ignoring the TeamCity build number. Since the XML metadata file is centralized, I can use the values to populate my Nuspec, AssemblyInfo, and WiX Installer metadata as well as pass the version and other pertinent information back to TeamCity through service messages.
I added a simple MVC web interface to allow my team to edit the file contents remotely if package details change. Now we have one single place to update things like Copyright information and any other metadata for a given build project. I can also give non-dev folks access to the MVC site to update branding information without allowing them access to my TeamCity build configurations.
With the exception of the service messages used to relay version to TeamCity, there's very little here that's coupled with TeamCity. I like having the functionality in custom targets and build scripts removed from TeamCity on the off chance we move to another build management solution. For that reason, I don't envision taking time to build a TeamCity plugin, but there could be a blog series coming soon.
I'll be happy to provide more code and further explanation to anyone interested.