All geek questions in one place

Workflow for continuous integration and automatic stamping of versions: .NET projects + CC.NET + SVN + MSBuild

I am using SVN + CruiseControl.NET + MSBuild to create .NET projects. This is a technology specific, so you understand the environment and my terminology, but the question is more general.

Now my CI workflow is pretty simple:

  • CC.NET detects new revision on project trunk detected in SVN
  • CC.NET working copy is updated with SVN
  • MSBuild runs against .proj file in trunk
  • Unit testing in progress
  • If successful, the project is copied / deployed.

In step 3, I want to “stamp” the version number on the assembly; in my case, in the AssemblyInfo.cs file, most likely using something like the AssemblyInfo task from msbuildtasks. In addition, I would like to be able to repeat this assembly on this particular version number. Right now, I think that probably after the 4th step, I will need to transfer / tag back the SVN project using the stamped AssemblyInfo.cs, but I had problems finding the easiest way to do this.

If I execute a project with a stamped AssemblyInfo.cs file back to the repository, it cannot be for the trunk, as this will cause another automatic collection: an infinite loop. Therefore, I would suggest that he would need to go to the new tag. So, I would mark the revision, switch the working copy to the tag, commit, and then switch back to the torso. Is this a common way?

Or am I complicating this too much? Do I even have to worry about fixing this assembly back to the repo or just fixing the built project and saving it in a structured place in the file system?

+4
source share
2 answers

You do not need the msbuild task to emboss the version. CCNET will do it for you. The msbuildtasks style task is only for TFS where it is not built in.

There is no reason to worry about checking the assemblyinfo file. As long as there is a label (or something like svn calls them), you're fine.

Regarding the retransmission of an exact copy of the assembly, I would say just fasten it and save the ones that are actually used. You do not need to store each assembly.

What I always did was the CI assembly, which runs on every test, plus the release assembly, which runs only manually for deployment. CI build does not get the version number at all and is not stored anywhere. Versioned version gets the version number and saved.

+1
source

In my current and previous company. we print / modify assemblyInfo.cs during assembly and complete assemblyInfo files after each successful assembly.

To prevent an endless loop; we exclude asssemblyInfo.cs from the trigger assembly in the ccnet configuration.

Disadvantage: whenever we press the force button, the new version will be transferred back to the trunk repository, even if there is no modification in the source code.

I'm still learning the best ways to control assemblyInfo versions :)

Added after 2 hours:

After some research; instead of returning the assembly back to the trunk; some people create a working directory tag (with a modified assembly) CCNET supports this mechanism: SVN TagOnSuccess working copy and updated AssemblyInfo.cs

Jeremy Miller takes this approach http://codebetter.com/jeremymiller/2007/12/06/do-you-really-know-where-that-code-has-been/

drawback: there will be many tags

+3
source

Source: https://habr.com/ru/post/1395308/

More articles:


All Articles