1
votes

I have created some custom CodeActivity-derived clases which:

  1. successfully check an assembly info file, GlobalAssemblyInfo.cs,

  2. changes the value of AssemblyFileVersion,

  3. and then checks it back in, returning the change set value.

I based some of this work on Ewald Hofman's wonderful blog Customize Team Build 2010 – Part 5: Increase AssemblyVersion

The Problem:

Later in the build, one of my projects in this solution uses the version number to create a subdirectory by getting the version number from the newly built assembly. The problem is the subdirectory always lags behind in the version number. I've noticed that when I test the build definition based on the BuildProcessTemplate, that my included change sets never include the GlobalAssemblyInfo from that build.

The build log tells me that steps 1, 2, and 3 all work. It also tells me that Associated Change Sets in the summary don't include the change set number in step 3. Does anyone know how I can work around this problem?

1

1 Answers

0
votes

I found the answer to this question experimentally. As soon as a build is started, that point in the version tree is used for the associated change sets. Since I am checking out and checking in a file after that point, it is not part of the build. I got around this problem by calling my GetLatest activity after the Get All (specific), as seen in the DefaultTemplate. It's accomplishes the goal of getting my changed version number used in the assemblies.