AssemblyVersion Automation

Question

Ive looked at the AssemblyInfo task on GDN:

http://www.gotdotnet.com/codegallery/codegallery.aspx?id=93d23e13-c653-4815-9e79-16107919f93e

and also Guatams post on using it in Team Build:

http://blogs.msdn.com/gautamg/archive/2006/01/04/509146.aspx

but it falls down for me for several reasons:

- it updates all assemblyinfo files before even attempting compilation of the first project so its not really appropriate for incremental builds where only certain projects will be rebuilt

- it doesn't allow for duplicate attribute names (with different attribute values) in a single assemblyinfo file

- it necessitates you checkin your automatic update to these files as this is how it increments it next time around

- it updates both AssemblyVersion and AssemblyFileVersion with the same values each time.

I want my devs to control when they update the AssemblyVersion attribute but the build process to update the AssemblyFileVersion for audit purposes. I thought I'd try and follow the lines of passing in a generated AssemblyFileVersion value directly from Team Build using this technique:

http://blogs.msdn.com/gautamg/archive/2006/04/20/579801.aspx

but although my AssemblyFileVersion is setup as an initial property (I can see this by turning on detailed logging for team build) it gets overriden by the value in assemblyinfo.cs during the compile - so I removed AssemblyFileVersion from the assemblyinfo file and it still ignores the value I pass in and sets AssemblyFileVersion to whatever AssemblyVersion is in the assembly info file!!

Is this technique worth pursuing or am I going to need to sort out the problems I have with the GDN assemblyinfo task (bearingin mind I'm not a .net developer, I'm a simple build man;-)

 

 

Answer 1

Jeff Atwood has a slightly different approach at http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/06/Adding_the_Build_Number_to_your_binaries.aspx.

The checkin is only done in AfterCompile, and the changes are undone if the build fails.

I don't have an answer for dealing with the second reason.

For dealing with the third reason, you could have some file on a share or somewhere else, but that's more fragile than using version control.

I'm not sure about the last issue.  You may want to try posting that question in the msbuild forum.

Buck