Category Archives: TFS

Build Template for TFS2010

I’ve had requests to provide a little more information regarding the multiple transformation article that I posted a long time ago.  Here is the build template for triggering the build on TFS 2010.  There is no explicit commands inside to invoke the multiple transformation.

Please rename the file to XAML, and edit the paths within to point to where your file is located.  You may also need the binaries from if you are editing in the UI designer

Also in this build template, I added the following

  • Add versioning to the compiled DLLs (based on TfsBuild.Versioning.Activities, link above)
  • Set Build Quality

Since the original post till today, the multiple transformation and build are still happening without issues.  Hope this helps!


XAML Build fails in TFS 2015 RC: Could not load file or assembly ‘Microsoft.Build.Utilities.Core, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies.

Mucking around TFX2015RC throws up some surprises.  Creating a new build XAML build definition / loading an old XAML definition will result in a cryptic build error.

Cannot Build

The current fix?  Install VS2015RC on the box – minimum installation options should suffice (unless you encounter that weird installation bug that prevents you from doing that).

build success

Hope that Microsoft packages that DLL into TFS directly, rather than required an entire install.  Microsoft, are you seeing this???

Issue installing VS2015RC on certain VMs (Visual C++ Redistributable for Visual Studio 2015 RC fails on Windows Server 2012)

I’m currently encountering issues with installing VS2015RC on some VMs that I have on hand (W2K12 upgraded to W2K12R2), as TFS XAML builds are not able to succeed without the presence of VS2015RC on them.  Symptoms of the errors I encounter include:

  1. Access Denied on various components during the installation
  2. Errors logged in installation log file

[1E58:06CC][2015-05-26T15:07:39]i301: Applying execute package: Windows81_x64, action: Install, path: C:\ProgramData\Package Cache\469A82B09E217DDCF849181A586DF1C97C0C5C85\packages\Patch\x86\Windows8.1-KB2999226-x64.msu, arguments: ‘”C:\Windows\SysNative\wusa.exe” “C:\ProgramData\Package Cache\469A82B09E217DDCF849181A586DF1C97C0C5C85\packages\Patch\x86\Windows8.1-KB2999226-x64.msu” /quiet /norestart’

[1E58:06CC][2015-05-26T15:07:39]e000: Error 0x80070005: Failed to open WU service.

[1E58:06CC][2015-05-26T15:07:39]e000: Error 0x80070005: Failed to ensure WU service was enabled to install MSU package.

[1E58:06CC][2015-05-26T15:07:39]e000: Error 0x80070005: Failed to execute MSU package.

[091C:14C8][2015-05-26T15:07:39]e000: Error 0x80070005: Failed to configure per-machine MSU package.

[091C:14C8][2015-05-26T15:07:39]i000: MUX:  Installation size in bytes for package: Windows81_x64 MaxAppDrive: 0  MaxSysDrive: 0  AppDrive: 0  SysDrive: 0

Managed to manually install the offending patch, but even after that, the installation still fails. (Thanks @sihuiwsh)

Apparently others have also encountered this problem, will keep an eye out and update here if a solution is found.(

Understanding AssemblyFileVersion

A few days ago, I was messing around trying to update the information of a DLL that was built on a central TFS server.  I was using a custom activity to interpret AssemblyInfo.cs, and change certain values before the final DLL was generated.  I came across an interesting observation and would like to share these findings, and maybe shed some insights to people who encounter such a behaviour.

For my test, I set the AssemblyInfo.cs as follows, then proceeded to build that DLL:

  • AssemblyVersion =
  • AssemblyFileVersion = 1.0.<SourceControlNumber>.<Date:yyMMddHHmm>, which happen to be 1.0.427.1403112154

I then queried that DLL using 3 different methods

  • Using ls *.dll -r | % versioninfo
    • ProductVersion = 1.0.427.1403112154 (Qn: Where did Product Version come from?)
    • FileVersion = 1.0.427.1403112154
  • Using PS with .NET classes, I get (as expected)
    • FileVersion = 1.0.427.1403112154
    • AssemblyVersion =
  • Using the view file properties in windows explorer, I get
    • FileVersion = 1.0.427.51930 (Qn: Where did this value come from?)
    • Product Version = 1.0.427.1403112154 (Qn: Where did Product Version come from?)

The results of these queries are show below



Let’s tackle the Product Version question first.  MSDN says

ProductVersion first looks to see if the assembly containing the main executable has the AssemblyInformationalVersion attribute on it. If this attribute exists, it is used for bothProductVersion and CommonAppDataPath. If this attribute does not exist, both properties use the version of the executable file instead.

So, since we did not set a AssemblyInformationalVersion, the DLL defaults to use FileVersion instead.  From what we see, this seems like the observed behaviour.  However, when I subsequently tried injecting a AssemblyInformationalVersion, the DLL still continues to show the File Version.  This will need further research.  Please share if you know why this is happening.


Next,  the File Version value presented in the file properties window differs from the actual value retrieved via powershell/.NET.  This different may cause confusion to anyone looking at the FileVersion information.  I spent a fair bit of time trying out various permutation to try to understand the behaviour.  The breakthrough came when I set FileVersion = 1.0.427.2014, which gave me this:


In this scenario, both File Version report the same result.  Looking up MSDN yields the following:

A file version number is a 64-bit number that holds the version number for a file as follows:

Putting together a quick test app, we see that a ushort (unsigned short, 16 bit number) parse of the original 1403112154 yields 51930!


So it seems that although you can push values larger than 16bit into each subset of fileversion, file properties renders it as a 16 unsigned short.  Hence, if you need to use file properties to retrieve such information, keep each subset of version to be no larger than what ushort can hold.

Hopes this helps someone someday.

Multiple TFS Build Controllers per Team Project Collection

This builds upon my previous post to mix domain and non-domain build servers together.  I wanted to have a controller each to manage the various build agents within the domain and non-domain build servers.  Enabling this was a piece of cake.

Head over to your TFS Admin Console on your Build Server, and create a new controller.


Reassign each agent to use the new controller by clicking on the Properties link, then update the Controller value.


Skip over to queue a new build.  You’ll notice that now you have 2 build controllers to select from.  Target the new BC and you’re done!

Non-Domain TFS Build Server with Domain TFS

With some spare time on hand, I wanted to explore if there we were to mix domain-joined build servers with non domain-joined ones, since this could open up a couple of interesting possibilities.

1. Ensure that the target TFS server is reachable, so that we can put proxy and firewall issues aside.

2. Install TFS, but select to only configure Team Foundation Build ServiceTFSBuildServiceOnly

2. Define the TFS Server, then select the Team Project Collection


3. Enter the credentials that your build service will run as.  Ensure that the necessary permissions have been granted, otherwise you’ll get a TF254021 surprise.


4. Continue with the installation, and you’re done!


5. So now you have a non-domain build service (with 2 agents) connected to a domain-joined TFS and Build Controller.





#To set the permissions, make sure that your TFS target is not a Domain Controller.  Create a local account (e.g. remotebuild) on TFS, your build controller and your Non-Domain Build Server. Make sure they have the same password. I also added the account to the Project Collection Build Service.

# Make sure that communication on port 9191 from Build Controller to your Build Agent is enabled.

TF30063: You are not authorized…!

But first, some background.  My connection to TFS is via HTTPS, using an internal CA signed SSL Cert.


HTTP works fine(using FQDN), but with custom domain names and HTTPS, sometimes it works, sometime it doesn’t.

When I connect to the HTTPS url via IE, the connection works, but no lock ICON appears.  If I repeat the same action inside the VS2013 browser (Ctrl-W, W), a revocation failure dialog sometimes pop up.  Regardless of selection, the authentication still fails.


I’ve tried the clear cookie method suggested, disabling cert revocation checks on the server (via netsh) and locally (via gpedit), or at least I think I did, but no luck yet.

This is irritating… Gah!

[Edit] Checked permissions as described here but still no go …

[Edit] Checked that server had a 3+ min delay compared to client, fixed that, cleared cache etc, but still no go…

[Edit] Seems to be no correlation between IE having a lock sign, and the revocation message inside VS browser.