How do you register files as part of an assembly in Visual Studio Team Services?

Question

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

We are in the midst of moving from local tfs to visual studio team services. Many of our current built-in modules update the version number in order to synchronize it with the build number and additionally check these files for the original control during assembly.

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

Now I try to check the files back to the original control, but I get an 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 am currently using tf.exe to try to do this. First enter 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 change the loop to check the file, and then check the files again.

 # 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 right way to do this? If the build service is not allowed access, how can it GET the code, compile it, and then POST the artifact somewhere?

Answer 1

I would not recommend checking the assembly version every time, instead I would recommend using the [assembly: AssemblyVersion("1.2.*")] Wildcard support (and I remove [AssemblyFileVersion] so that it automatically matches.

Checking modified files after build has problems in several ways:

• The function of index and symbol sources will use sources that do not correspond to the code associated with the set of changes. This will break advanced debugging scripts.
• Advanced testing features break down and may offer unwanted tests or changes.
• History cluttered **NO_CI** changeets
• This breaks semantic versioning because these types of scripts do not affect breaking API changes and can cause fun behavior.

---

I created a new build task that will allow you to check files using the task:

• https://github.com/jessehouwing/vsts-tfvc-tasks/tree/master/vsts-tfvc-checkin

Add it to your visualstudio online from an instance of TFS 2015 using the tfx console:

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

I am still working on deferring the addition and deletion, but I am encountering problems with the client object model somehow not expecting anything but changes.

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

For more information:

• http://blog.jessehouwing.nl/2016/01/manipulating-your-tfvc-repository-from.html

Answer 2

As I already said.

I would rather discard changes to AssemblyInfo.* Files than check them out in the original control.

In my case, I use 1.$(date:yy).$(date:MMdd)$(rev:.r) as the assembly number format

So, I will never read the version from AssemblyInfo.* Files, so what's the point of saving this information?

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

If you want to synchronize the source code with a specific version, you can use the same build number format to indicate the source code.