OT: Automated builds & maintenance branch

ajj3085 posted on Tuesday, November 14, 2006

Hi,

So, I have CCNet setup for each of my assemblies.  If a build is successful, it ends up on the R: drive, which is a network drive to a server.  On R:, there is a folder for each assembly, and the latest is in the root of that folder.  All is well.

Now, I have a maintenance branch.  I'm setting up a seperate instance of CCNet to do automated builds of the branch.  My problem is this; opening a solution for maitenance will cause it to look to the R: drive for the latest version of all custom assemblies it needs. 

I could create another drive, M: and have the maintenance projects point to that, but I'm concerned that merging the csproj files down the line will be troublesome..

Anyone have alternate solutions, or am I worrying too much about the merge later?

Andy

Bayu replied on Tuesday, November 14, 2006

Hey,

What is CCNet?

Google told me it could be CruiseControl.Net, some online course-class tool and Wikipedia told me it was the Cambridge Conference Network ........


I guess that if you answer the former question, the following will become apparent, but for now: what do you mean by a maintenance branch?

Are you talking about client installations, developer builds or something like overnight builds on a build machine that builds whatever was checked in today on your source control server?

More than willing to help ....and I might have relevant experience but I'm not sure (yet)... as you probably noticed I am kind of lost so far ... ;-)

Regards,
Bayu

ajj3085 replied on Wednesday, November 15, 2006

CCNet is CruiseControl.Net.  I should remember to always spell out acrynoms :-)

By maintanence branch I mean this; I have a version in production, 2006.11.14.14 which the users are using.  I need to continue development on new functionality, but at the same time if a bug creeps up in the current version, I need to be able to fix it and release a new production version, without the development code.  So I used the Branch feature of Vault, which takes the current version of everything and creates a copy of it.  Now I can edit the two branches independantly.

Later, when I finish the new features, I will merge the maintance branch into the development branch, so that all my bug fixes make it into the development branch, and the development branch will have both new features and bug fixes.

Andy

Bayu replied on Wednesday, November 15, 2006

Aight, this means I cannot answer your question. I have no experience with CruiseControl.Net. We make heavy use of SubVersion, our policy there is to always rely on merging, which works fine.

Any CruiseControl guru in the house?

Bayu

ajj3085 replied on Wednesday, November 15, 2006

This isn't strictly a CCNet issue.

My main concern is the HintPath element in the .csproj files point to an R: drive, and for the automated maintance builds I want it to point somewhere else.

I think what I'll do is for both servers, not use the R: at all and instead build a nant task to figure out reference paths.  Each server will have different settings for the build, and the nant task I build will take a 'referenceRoot' parameter which it will use to build a full path. 

Without the R: drive, the hintpath won't work, so MsBuild will fall back to the ReferencePath property passed.

I'll post back my results.

Andy

msk replied on Thursday, November 16, 2006

I have come across the same problem.  Fortunately we are able to avoid doing branches in the code, so I have dodged it.  But I would like our build process to build both Debug and Release builds - where the Debug version references Debug Assemblies and the Release version references Release versions.  The only option I came up with was to replace the references in the project file.  I haven't looked at it since the arrival of MsBuild.  I'd be interested to see your results. 

ajj3085 replied on Thursday, November 16, 2006

msk,

I remove the mapping, so the Hintpath values are no longer valid directories. I can then pass the reference paths to msBuild, by using the /p:ReferencePath=<paths>

Its not as easy as you'd think though; if you have more than one, they need to be seperated by a semicolon.  However, if you use semicolon, msbuild thinks the second path is a property name, so you have to enclose the whole semicolon list in quotes.  So my build task in nant looks like this:

      <resolveReferencePaths projectFile="${LocalSolutionRoot}\${SolutionName}\${SolutionName}.csproj"
        referenceRoot="${DeploymentLocationRoot}" property="ReferencePaths"/>

      <exec basedir="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727" program="msbuild.exe">
        <arg value="/nologo" />
        <arg value="${LocalSolutionRoot}\${SolutionName}.sln" />
        <arg value="/p:OutputPath=${LocalSolutionBin}" />
        <arg value="/p:SignAssembly=true" />
        <arg value="/p:AssemblyOriginatorkeyFile=${LocalShared}\MyCompany.snk" />
        <arg value="/p:Configuration=Release" />
        <arg value="/p:ReferencePath=&quot;${ReferencePaths}&quot;" />
      </exec>

Now, whast is resolveReferencePaths?  Its a custom nant task that looks at the project file and selects all the Reference nodes.  It assumes that the folder is the same as the name of the assembly.  For example, MyCompany.Core.dll is in MyCompany.  ${DeploymentLocationRoot} is a location where release versions of all assemblies are found, in my case c:\inetpub\wwwroot\releases, which contain folders for the assemblies.

Not only does that task look at the project file, it then examines the reference assemblies as well to find anything they might need (since the assemblies are tested, so they'll need the subdependencies too). 


I'd post code for the nant task, but I'm not sure if I would be allowed to.  Its fairly trivial to implement anyway, its just getting some nodes from an xml file and then using some reflection to examine the actual references.  The task is smart enough to ignore anything that is System, Microsoft, mscorlib or Infragistics.

Everything seems to be working fine now... the only problems I've now run into are:

1.  Source control bindings need to be fixed for the maitanence branch; not a big deal, I'll do that as I go (you get a warning about invalid references on loading). 

2.  The hintpaths on my development machine are valid, because I always reference the network drive.. so I have to be careful and remember to update them.

This will still likely cause some headaches when I go to merge...or I guess I could just disconnect the network drive and retarget it when I switch between maint and development..

HTH
Andy