Home/ Questions/Q 7433205
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T09:34:42+00:00

I’m using SVN + CruiseControl.NET + MSBuild to build .NET projects. These are the

  • 0

I’m using SVN + CruiseControl.NET + MSBuild to build .NET projects. These are the technology specifics so that you understand the environment and my terminology, but the question is more general in nature.

Right now, my CI workflow is pretty simple:

  1. CC.NET detects new revision to the project trunk detected in SVN
  2. CC.NET working copy is updated from SVN
  3. MSBuild is launched against a .proj file at the trunk
  4. Unit tests run
  5. If successful, project is copied/deployed

At step 3, I would like to “stamp” the version number onto the build; in my case, in the AssemblyInfo.cs file, most likely using something like the AssemblyInfo task from msbuildtasks. As well, I would like to be able to repeat that build at that specific version number. Right now, I’m thinking that probably after step 4, I’ll need to commit/tag back to SVN the project with the stamped AssemblyInfo.cs, but I’m having trouble thinking about the most straightforward way to do this.

If I’m committing the project with the stamped AssemblyInfo.cs file back to the repository, it cannot be to the trunk since that will trigger another automated build: infinite loop. So, I would assume that it would need to go to a new tag. So then I would tag the revision, switch the working copy over to the tag, commit, then switch back to trunk. Is that the common way?

Or am I over-complicating this? Should I even be worrying about committing this build back to the repo or just ZIPping up the built project and storing in a structured location in the file system?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You don’t need a msbuild task for version stamping. CCNET will do this for you. msbuildtasks style task is just for TFS where this isn’t built in.

    There is no reason to worry about checking in the assemblyinfo file. As long as there is a label (or whatever svn calls them) you are fine.

    As far as rerunning an exact copy of the build, I’d say just zip them up and store the ones that actually are used. You don’t need to store every build.

    What I have always done is have a CI build which is run on every checkin plus a release build that is only run manually for deployments. The CI build doesn’t get a version number at all, nor is it stored anywhere. The versioned build gets a version number and is saved.

    • 0