How do you checkin files as part of the build in Visual Studio Team Services?

Question

I'm trying to figure out how to close the loop in our build process where we apply a version number to the AssemblyInfo.* files as part of the build process.

We are in the midst of migrating from on-premise tfs to visual studio team services. Many of our current on-premise builds update the version number to keep it in sync with the build number and additionally check those files back into source control during the build.

I've successfully used the script located on msdn as an example to start customizing the build process.

I'm now attempting to check the files back into source control but I'm receiving the error:

#[error]TF30063: You are not authorized to access https://subdomain.visualstudio.com/DefaultCollection.
#[error]Process completed with exit code 100 and had 1 error(s) written to the error stream.

I'm currently using tf.exe to attempt to do this. First get the path to the tool at the top of the powershell script;

# get the tf command line tool path
$tfexe = [System.IO.Path]::GetFullPath($env:VS140COMNTOOLS + "..\..\common7\ide\tf.exe")
if (-Not (Test-Path $tfexe))
{
    Write-Error "Could not find tf.exe at '$tfexe'"
    exit 1
}
else
{
    Write-Host "Found tf.exe at '$tfexe'"
}

Then modify the loop to checkout the file and then check the files back in.

# Apply the version to the assembly property files
$files = gci $Env:BUILD_SOURCESDIRECTORY -recurse -include "*Properties*","My Project" | 
    ?{ $_.PSIsContainer } | 
    foreach { gci -Path $_.FullName -Recurse -include AssemblyInfo.* }
if($files)
{
    Write-Host "Will apply $NewVersion to $($files.count) files."

    foreach ($file in $files) {

        #Write-Host "Attempting to checkout file '$file'"
        & ($tfexe) vc checkout $file

        $filecontent = Get-Content($file)
        attrib $file -r
        $filecontent -replace $VersionRegex, $NewVersion | Out-File $file
        Write-Host "$file.FullName - version applied"
    }

    # Checkin pending changes together
    ##[error]TF30063: You are not authorized to access https://subdomain.visualstudio.com/DefaultCollection.
    ##[error]Process completed with exit code 100 and had 1 error(s) written to the error stream.
    Write-Host "Attempting to checkin files"
    $comment = "Applied $NewVersion to $($files.count) files.  ***NO_CI***"
    & ($tfexe) vc checkin /comment:"$comment" /noprompt
}

Is this the proper way to be doing this? If the build service is not authorized to access, how the heck can it GET the code, compile it, and then POST the artifact somewhere?

Answer 1

I would not recommend to check in the assembly version every time, instead I'd recommend to use the [assembly: AssemblyVersion("1.2.*")] wildcard support (and I remove the [AssemblyFileVersion] so it's automatically matching.

Checking in the changed files after the build has issues in a number of ways:

• The Index Sources and Symbols feature will be using sources that don't match the code associated with the changeset. This will break advanced debugging scenarios.
• Advanced test features break and may suggest unwanted tests or changesets
• History is cluttered with **NO_CI** changesets
• It breaks semantic versioning as these kinds of scripts don't factor in breaking API changes and may cause funny behavior.

---

I created a new build task which will allow you to check-in files using a task:

• https://marketplace.visualstudio.com/items?itemName=jessehouwing.jessehouwing-vsts-tfvc-tasks
• https://github.com/jessehouwing/vsts-tfvc-tasks/tree/master/vsts-tfvc-checkin

Add it to your visualstudio team foundation services or TFS 2015 instance using the tfx console:

tfx build tasks upload -taskpath path\to\project\root

I'm still working on a way to pend adds and deletes, but I'm running into issues with the Client Object Model somehow not pending anything other than edits.

it looks like calling tf add and tf delete will actually work in the build script in combination with this checkin task.

For more information:

• https://marketplace.visualstudio.com/items?itemName=jessehouwing.jessehouwing-vsts-tfvc-tasks
• https://jessehouwing.net/vsts-build-manipulating-your-tfvc-repository/

Answer 2

As I commented before.

I would rather discard the changes on AssemblyInfo.* files than check them into the source control.

In my case I use 1.$(date:yy).$(date:MMdd)$(rev:.r) as a build number format

So I will never read back the version from the a AssemblyInfo.* files, so what is the point of saving that information?

The build number format will generate the version again regardless the value stored of the AssemblyInfo.*

If you want to sync source code with an specific version you could use the same build number format to label the source code.