Tag Archives: TFS

XAML Build fails in TFS 2015 RC: Could not load file or assembly ‘Microsoft.Build.Utilities.Core, Version=14.0.0.0, 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.(https://social.msdn.microsoft.com/Forums/en-US/64baed8c-b00c-40d5-b19a-99b26a11516e/visual-c-redistributable-for-visual-studio-2015-rc-fails-on-windows-server-2012?forum=vssetup&prof=required)

Configure/Reinstall/Setup Build vNext Agent on TFS2015RC

I’ve been messing around TFS2015RC these days, and one of the coolest new feature is the Build vNext Preview.  However, it is not smooth sailing and one of the issues that cropped up was that the Build vNext Agent failed to install correctly during the setup process because I forgot to set up the proxy server, which led to the agent not being able to locate the TFS server (TF402467).

Heading back into the TFS Admin Console confirms this.

TFS2015RCBuildAgentFail

Attempts to “Change Account” or set the “Work Folder” would fail because of a “corrupt setting.json” file.

Digging into “C:\Program Files\Microsoft Team Foundation Server 14.0\Build” would show a setting.json with seemingly empty values.  However, a ConfigureAgent.ps1 seems promising.

Call the powershell script, and provide the required values (assuming you have already sorted out the issue that caused the failure in the first place)

PS C:\Program Files\Microsoft Team Foundation Server 14.0\Build> ./ConfigureAgent.ps1
Enter the name for this agent (default is Agent-TFS2015RCDEMO):
Enter the url for the Team Foundation Server (default is ): http://localhost:8080/tfs
Configure this agent against which agent pool? (default pool name is ‘default’):
Enter the path of work folder for this agent (default is ‘C:\Program Files\Microsoft Team Foundation Server 14.0\Build\_
work’):
Would you like to install the agent as a Windows Service (Y/N) (default is Y):
Enter the name of the user account to use for the service (default is NT AUTHORITY\LocalService):
Would you like to unconfigure any existing agent (Y/N) (default is N; the agent will be updated):
Configuring agent
Unblocking files
Calling agent configure with /RunningAsService
Calling agent configure without /Force
Installing service vsoagent.localhost.Agent-TFS2015RCDEMO…
Service vsoagent.localhost.Agent-TFS2015RCDEMO has been successfully installed.
Creating EventLog source vsoagent.localhost.Agent-TFS2015RCDEMO in log Application…
Configure agent succeeded.
Agent is now running as a Windows Service.
PS C:\Program Files\Microsoft Team Foundation Server 14.0\Build>

Jumping back to the TFS Console Admin, we see that the Build vNext Agent has been set up and running.  Yay!  Hope this helps someone!

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 = 1.0.0.0
  • 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 = 1.0.0.0
  • 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

image

 

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:

image

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!

image

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.

MultiBCCreateNewControlelr

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

MultiBCModifyAgent

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

TFSBuildServiceSelectServer

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.

TFSBuildServiceAccount

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

TFSBuildServiceSuccess

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

 

 

 

Note:

#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.

Server

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.

Revocation

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.