TFS 2018 XAML build migration - tfs

Question

I am currently upgrading our XAML build definitions to the new build system. Already squashed a few errors, but now I am at a point where I can no longer tell what could be wrong. We use PowerShell scripts for most of the build process, and although all required data is available on the server, I get the following error when running the build:
Does anyone have any idea what could cause that error? Or at least where I should check?
Thanks in advance.
EDIT:
The script prepares build configuration that can not be done by external tools and are specific to our project. The error happens on the line $teamProjectCollection =...
Function Get-BuildNumberFromUri() {
<#
.SYNOPSIS
Reads the build number from the current TFS build ($Env:BUILD_BUILDURI)
.DESCRIPTION
Reads the build number from the current TFS build ($Env:BUILD_BUILDURI)
.NOTES
May fail if $env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI or $env:BUILD_BUILDURI
are not set
#>
[String] $CollectionUrl = "$env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI"
[String] $BuildUrl = "$env:BUILD_BUILDURI"
if (-not $CollectionUrl -or -not $BuildUrl) {
return "0"
}
[void[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Build.Client")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.VersionControl.Client")
$teamProjectCollection = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($CollectionUrl)
$buildServer = $teamProjectCollection.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer])
$buildDetail = $buildServer.GetBuild($BuildUrl)
$buildNumber = $buildDetail.BuildNumber
return $buildNumber
}

Answer 1

Here's the problem:
You're using a new build system. You need to step back and re-evaluate the existing scripts you have in context of the capabilities of the new build system.
You have this big PowerShell snippet that retrieves the build number. That's awesome, except for two things:
It's never going to work -- the SOAP object model does not have any awareness of "new" (e.g. non-XAML) builds. There is a REST API for them, instead.
You can retrieve the current build number by looking at the $env:BUILD_BUILDNUMBER variable. No special code necessary.

Answer 2

In previous versions of Team Foundation Server the Client Object Model was registered in the GAC and pre-loaded by the build agent when running XAML. In the new agent the build steps are independent of the client object model.
You have two options to locate the Client Object Model assemblies:
Ship the Client object model with the powershell scripts by referencing the Client Object Model Nuget package.
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.Client
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.ExtendedClient
Detect the location where Visual Studio is installed and loading the client object model from the Team Explorer extension folder. Examples can be found on the docs wiki.
There is also an easier, but officially unsupported option:
Do not use $(Agent.ServerOMDirectory). It is not safe for task authors to depend on the SDK bundled with the agent. Agent.ServerOMDirectory is a convenience variable that points to the latest SDK bundled with the agent. The SDK may have breaking interface changes between different versions. Depending on the latest version shipped with the agent will cause your task to be unreliable.
Getting at the buildnumber
There is a build variable being populated to set the build number in your script it can be referenced using $env:Build.BuildNumber.
To set the build number write a special statement to the console using
$value = "$($env:Build.BuildNumber)_US`
Write-Host "##vso[build.updatebuildnumber]$Value"
Alternatively you can use my Set Variable task from the VSTS Variable Toolbox extension.