views:

420

answers:

3

Hi,

I've been looking into the following:

  1. With an existing AssemblyInfo.cs file change the AssemblyFileVersion to the current date and time,i.e. YYMM.DD.HH.MM
  2. Take the date and time used in (1) and label the sourcecode with it (in SourceSafe)

I've managed to get MSBuild file and CC to integrate but I need to pass out of the MSBUILD file a variable that I can then pass to a CC task to label sourcesafe if the build completes.

Any ideas?

A: 

One Idea would be to have your MSBuild create an environment variable with what it labled with, then it would be available in all subsequent tasks for this project. However I am wondering why you would use date time in this format, since both spots for all intents and purposes already would have the date. Why not use a meaningful label like build number, then have MSBuild grab the labeler format from the state file and use that to update the Assembly infos. Then your labeler would just use that anyways. No need to retain and transfer. The reason I say time/date is irrelevant is that the normal process will all ready tell you that date/time the label and exe were created. Why do it twice?

Alex
A: 

In my experience, it's CCNet that is typically generating the build number (in your case, based off the current date and time). You will want to use the Date Labeller in your ccnet.config file.

There is an AssemblyInfo task in the the MSBuild Community Tasks Project. You specify the target AssemblyInfo.cs file and what values to assign to which attributes.

The build label generated by CCNet is passed to MSBuild via the $(CCNetLabel) variable. This is done automatically when CCNet calls MSBuild, so you can just start using $(CCNetLabel) in your MSBuild file. That takes care of #1 above.

For #2 you'll want to add this in your SourceControl block of your ccnet.config file:

<applyLabel>True</applyLabel>

This will cause the version to be applied as a label in Visual SourceSafe if your build succeeds.

Josh Kodroff
A: 

Hi, thanks so far.

To answer the queries:

Our DLL's are stamped with a hardcoded version (e.g. 1.2.0.1) that we define manually. This is the Assembly Version in the AssemblyInfo.cs file and it does not change unless we issue a new release from development into QA. These are the corporate procedures so I can't really change it.

The AssemblyFileVersion is to be timestamped by the build server, YYMM.DD.HH.SS. This tells us exactly when the DLL's were compiled regardless of the build number which is useful if it all goes to pieces in live.

I looked at the AssemblyInfo task but it generates the AssemblyInfo file for us - we do not want, nor need, this to occur as we already have an AssemblyInfo file with all the settings configured (except for AssemblyFileVersion that the build server will override).

To clarify what we have already (I was a little unclear, apologies). 2 CC Tasks:

1) MSBUILD task called by CC. This contains two steps - first to generate the current DateTime and second to update the AssemblyInfo.cs file (both done via MSBUILD community tasks) 2) MSBUILD task called by CC to perform the build (basically just runs the Solution File so it keeps it nice and easy for developers who use the same file in VS when they are developing and testing)

What I'd like is a way for the timestamp generated by step (1) to be passed back out to CCNET so that I can create a Step (3) which would be a CC task to label sourcesafe with the date/time if step (2) completed. I'm happy to do step (1) in CC but I couldn't find the tasks to do it, so used the MSBUILD tasks instead.

I'll look into the Environment Variable - I assume you don't mean the Windows Environment Variables... this is a CC thing?

Graham