Dependency Replication with TFS 2010 Build
- by Jakob Ehn
Some time ago, I wrote a post about how to implement dependency replication using TFS 2008 Build. We use this for Library builds, where we set up a build definition for a common library, and have the build check the resulting assemblies back into source control. The folder is then branched to the applications that need to reference the common library. See the above post for more details. Of course, we have reimplemented this feature in TFS 2010 Build, which results in a much nicer experience for the developer who wants to setup a new library build. Here is how it looks: There is a separate build process template for library builds registered in all team projects The following properties are used to configure the library build: Deploy Folder in Source Control is the server path where the assemblies should be checked in DeploymentFiles is a list of files and/or extensions to what files to check in. Default here is *.dll;*.pdb which means that all assemblies and debug symbols will be checked in. We can also type for example CommonLibrary.*;SomeOtherAssembly.dll in order to exclude other assemblies You can also see that we are versioning the assemblies as part of the build. This is important, since the resulting assemblies will be deployed together with the referencing application. When the build executes, it will see of the matching assemblies exist in source control, if not, it will add the files automatically: After the build has finished, we can see in the history of the TestDeploy folder that the build service account has in fact checked in a new version: Nice! The implementation of the library build process template is not very complicated, it is a combination of customization of the build process template and some custom activities. We use the generic TFActivity (http://geekswithblogs.net/jakob/archive/2010/11/03/performing-checkins-in-tfs-2010-build.aspx) to check in and out files, but for the part that checks if a file exists and adds it to source control, it was easier to do this in a custom activity: public sealed class AddFilesToSourceControl : BaseCodeActivity
{
// Files to add to source control
[RequiredArgument]
public InArgument<IEnumerable<string>> Files { get; set; }
[RequiredArgument]
public InArgument<Workspace> Workspace { get; set; }
// If your activity returns a value, derive from CodeActivity<TResult>
// and return the value from the Execute method.
protected override void Execute(CodeActivityContext context)
{
foreach (var file in Files.Get(context))
{
if (!File.Exists(file))
{
throw new ApplicationException("Could not locate " + file);
}
var ws = this.Workspace.Get(context);
string serverPath = ws.TryGetServerItemForLocalItem(file);
if( !String.IsNullOrEmpty(serverPath))
{
if (!ws.VersionControlServer.ServerItemExists(serverPath, ItemType.File))
{
TrackMessage(context, "Adding file " + file);
ws.PendAdd(file);
}
else
{
TrackMessage(context, "File " + file + " already exists in source control");
}
}
else
{
TrackMessage(context, "No server path for " + file);
}
}
}
}
This build template is a very nice tool that makes it easy to do dependency replication with TFS 2010. Next, I will add funtionality for automatically merging the assemblies (using ILMerge) as part of the build, we do this to keep the number of references to a minimum.
