0

I wanted to post replies to the following post...

Check-Out files from TFS 2010 with powershell

... but I couldn't as I don't have the Reputation yet.

Anyway, I need to check out AssemblyInfo* files recursively to adjust versioning information during our TFS Build process. I've been playing around with pre-build scripts from the Build Definition, but it doesn't seem to be having an effect (modified from the above post)...

#Checking out fileS
if ((Get-PSSnapin -Name  Microsoft.TeamFoundation.PowerShell -ErrorAction SilentlyContinue) -eq $null )
{
    Add-PsSnapin  Microsoft.TeamFoundation.PowerShell -ErrorAction SilentlyContinue

    if ((Get-PSSnapin -Name  Microsoft.TeamFoundation.PowerShell -ErrorAction SilentlyContinue) -eq $null )
    {
        #try to check out the code using command line tf.exe
        &"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\TF.exe" checkout AssemblyInfo* /recursive | Out-Null
    }
    else{
        #checkout the file using snapin
        Add-TfsPendingChange -Edit AssemblyInfo*| Out-Null
    }
}else{
    #checkout the file using snapin
    Add-TfsPendingChange -Edit AssemblyInfo*| Out-Null
}

As you can probably see, I'm no PowerShell guru, but I want to learn. I hacked away and combined some of the concepts in the above linked post, but it isn't working as a pre-build script. I just wanted to see that the files were checked out during the build (not checked in yet for testing purposes), but after the build completes, there are no files checked out in TFS. I'm not sure if something else is checking the files in from the TFS build itself, but it doesn't appear that the script is working.

What I would like to do is check out the AssemblyInfo files recursively, update the versions, compile the binaries, then possibly launch a post-build script to check the files in.

I found a versioning script here that appears to work and seems easy to implement. I was hoping to combine the concepts of checkout and versioning into one script.

Can anyone lead me in the right direction or illustrate what I am doing wrong? I guess I should state I'm using TFS/VS 2013.

Community
  • 1
  • 1
Superfreak3
  • 11
  • 7
  • 2
    Why would check-out/in the AssemblyInfo files? The idea is to update the version with the build number which is changing with each build. The build downloads the files from source control, the pre-build script updates the version and the source files are compiled. – ds19 Jun 04 '15 at 05:09
  • I'm not sure why you would not. I do have a script that seems to get the File and Product versions to the newly compiled binaries, but the version change is not held within the AssemblyInfo files. I was thinking that by checking in the edited AI files, it would kind of tie them to a particular build. I'm thinking TF Build only does a Get Latest and Compiles everything. Like I said, from the second link I posted, that is the script I currently tested to ensure files are versioned as intended, but again the change does not persist. – Superfreak3 Jun 04 '15 at 13:36
  • The purpose of "stamping" the AI files with the build number is to easy trace back a compiled file to its source file. This can be achieved by labeling the source files automatically by the build. Then you'll have a dll file with file version set to 2015.6.4.6 and the source files labeled in TFS with _2015.06.04.6 (if you use the default values of build parameters). In that way you'll be able to restore that specific version of files in your workspace. – ds19 Jun 04 '15 at 15:09
  • You can find a better explanation [here](http://geeks.ms/blogs/jlsoria/archive/2014/02/17/get-your-binaries-versioned-automatically-in-less-than-5-minutes-with-tfs-build-2013.aspx) – ds19 Jun 04 '15 at 15:14
  • Is labeling of the build a setting in the Build Definition? I seem to remember that it is, but I'm not at that system at the moment. Also, if I go the labeling route, is the AssemblyInfo file actually altered and checked in? In other words, currently my AI file has versions of 1.0.0.0, for example. Using the script to stamp the binaries, the files would then carry the version of 10.0.0.$Rev or something to that effect. My AI files still have 1.0.0.0 in them however. I'll check my build definition for the Label option and check the resulting AI file in TFS post build. – Superfreak3 Jun 04 '15 at 20:00
  • Also, I would want the AI file's versions actually changed so that Developers won't have to worry about what to set versions to if they have to compile manually. – Superfreak3 Jun 04 '15 at 20:05
  • Oh, I checked and the Build Definition is creating a label with each build already. So that ties the AI files to a particular build. I think I would still like to check out the AI files, modify, then check back in post build. What does that hurt, if anything? – Superfreak3 Jun 04 '15 at 20:12

0 Answers0