Recently in CruiseControl Category

A quick and dirty hack (written in C#) to solve the issue of MySql query log files getting huuuge:

System.ServiceProcess.ServiceController sc = new ServiceController("mysql", "servername");
sc.Stop();
Console.WriteLine("Stopping");
sc.WaitForStatus(ServiceControllerStatus.Stopped, new TimeSpan(0, 0, 30));
Console.WriteLine("Stopped");
System.IO.File.Delete(@"\\servername\C$\Program Files\MySQL\MySQL Server 5.0\data\ServerName.log");
Console.WriteLine("Starting");
sc.Start();
sc.WaitForStatus(ServiceControllerStatus.Running, new TimeSpan(0, 0, 30));
Console.WriteLine("Started");

I have this compiled into a CruiseControl task that runs at 7am every day, no more massive log files and a lot easier than trying to decipher the MySql documentation. Plus, I've got some other odds and ends of maintenance that I've shoe-horned in. Not necessarily elegant, but it works!

The ccnet.config for the server I inherited ownership of has since that happened contained a series of DTD entries to save having repeated blocks of markup in it. Up until very recently the only entities defined were for VSS Configuration (for "sourcecontrol" blocks), NANT Binary and NANT Binary with a Target parameter defined. See the example below for the NANT Binary with a Target parameter defined:

<!DOCTYPE cruisecontrol [
    <!ENTITY nantbin "<executable>C:\BuildServer\tools\nant\bin\nant.exe</executable>
                <targetList>
                    <target>full</target>
                </targetList>">
]>
<cruisecontrol>
...

I've just started started trying to separate out the ccnet.config as there are nearly 80 projects in there now and it's getting a tad difficult to read. A bit of judicious googling found me the "Multiple Projects" page on the cruisecontrol.net website. So without further ado I promptly separated our ccnet.config into one file per queue, plus a master one to glue it all together. A couple of pitfalls I encountered:

1 - Make sure that your sub-files actually get deployed to your CCNet's \server folder. Ours are self-deployed by a "BuildServerUpdate" build script and I forgot to add them to the list of files it copied from its VSS source folder to the \server folder in CruiseControl.
2 - Make sure your entity names are lower case
3 - Make sure that after splitting your file and thus creating the entities (see the "Splitting the ccnet.config file" section of the Multiple Projects page) you actually remember to put them in the body of the page. I didn't and spent a good while scratching my head!

Take a trip to the Microsoft Software License Terms page on microsoft.com. Once you've suffered through all the postbacks just to get to the Visual Studio 2008 English Retail license terms, take a read of parts 1 and 2.

1.  OVERVIEW.
b.  License Model.  The software is licensed on a per user basis.
2.  INSTALLATION AND USE RIGHTS.
a.  General.  One user may install and use copies of the software to design, develop, test and demonstrate your programs.  Testing does not include staging on a server in a production environment, such as loading content prior to production use.

Does, based on the bits highlighted in bold, this mean that a buildserver doesn't require its own licensed copy of Visual Studio, as long as each and every developer is using a licensed copy of the same edition of Visual Studio as installed on the buildserver? I'd love to know the definitive answer to that!

I suspect the answer is "the buildserver needs its own copy", in which case "boo hiss boo", but that's what we've paid for, to be on the safe side.

Previously: Migrating a CruiseControl.net server from x86 to x64.

Not particularly related to the conversion from x86 to x64, but if you're using PSEXEC to execute things remotely in your build scripts, such as MSI installers, remember that it will pop up (on first execution, per machine, per user) a license agreement window. You can see builds time-out and be wondering why if you don't spot this.

A couple of things to remember:

1. Most, if not all, of your installed tools that the build scripts use will need any references to C:\Program Files\ changed to C:\Program Files (x86)
2. Force ncover and nunit-console to 32-bit. Seriously, if you get the message "Profiled process terminated. Profiler connection not established" when chaining nunit-console through ncover, follow those instructions.

Those are my saving graces!

If you have an ASP.net web site (Visual Studio 2005 heritage from when project files disappeared), you might be using Visual Studio to build it into an MSI Installer in your CruiseControl.NET build server. If you're not, lucky you! :)

If you are, it's useful to be able to see Visual Studio's build output in the build log CC shows you, so try this:

  <target name="build.devenv90.website">
    <exec program="${DevEnvExe.90}">
      <arg value='/Rebuild release "C:\BuildServer\VSS\WebSite\Website.sln" /Out "c:\buildserver\vss\website\vs_errors.txt"' />
    </exec>
    <trycatch>
      <try>
        <loadfile 
          file='C:\buildserver\vss\WebSite\vs_errors.txt'          
          property='VisualStudio.Output'
        />
        <echo message='${VisualStudio.Output}' />
      </try>
      <catch>
        <echo message='*** Visual Studio Output Failed ***' />
      </catch>
    </trycatch>
  </target>

The trick there is using the loadfile task to pull Visual Studio's output into a property and then echo-ing it. Nothing more exciting than that really!

At the moment one of my projects is to harmonise all our build scripts so instead of having one per project (DLL's, Websites, WebServices, WinServices, EXE's) we have a StandardDLL, StandardWebsite, StandardWebService,.... This will take us down from over 50 build scripts to approximately 10-15 once "system" ones are included.

One thing that caused me a small problem was the fact that, within our DLL's, we have different levels of coverage attained and there is no realistic likelihood of the level of coverage being harmonised anytime soon (Yes, yes, ideal world = 100% coverage, etc). So, how to achieve this when using a standardised build script called StandardDLL.build?

The Build Script

<target name="ncoverage">
  <ncover program="${ToolsPath}\ncover\1.5.6\NCover.Console.exe"
    commandLineExe="${ToolsPath}\nunit\bin\nunit-console.exe"
    commandLineArgs="${ProjectName}.Test.dll /xml=${NCoverOutput}\${ProjectName}_Coverage.xml /labels /nologo"
    workingDirectory="${ProjectBasePath}\src\test\bin\${configuration}\"
    coverageFile="${NCoverOutput}\${ProjectName}_Coverage.xml"
    logLevel="Verbose"
    logFile="${ProjectBasePath}\src\test\bin\${configuration}\ncover.log"
    excludeAttributes="CoverageExcludeAttribute;System.CodeDom.Compiler.GeneratedCodeAttribute">
      <assemblies basedir="${ProjectBasePath}\src\test\bin\${configuration}\">
        <include name="${ProjectName}.dll" />
        <exclude name="*.Test.dll" />
      </assemblies>
  </ncover>

  <ncoverexplorer 
    program="${ToolsPath}\NCoverExplorer\ncoverexplorer.console.exe"
    outputDir="${NCoverOutput}\" 
    satisfactoryCoverage="90" 
    reportType="4" 
    failMinimum="true"
    projectName="${ProjectName}"
    xmlReportName="${ProjectName}_Coverage_Report.xml">
    <fileset>
      <include name="${NCoverOutput}\${ProjectName}_Coverage.xml" />
    </fileset>
  </ncoverexplorer>
</target>

The key bit is marked in bold, the "satisfactoryCoverage" node. I needed a way to have this configurable on a per-project basis, but without having to specify it for all projects (Just to be awkward!).

The Solution
It turned out the solution was quite simple; firstly replace the hard-coded "90" with "${satisfactoryCoverage}", i.e. a nant property. Secondly, add a new action just above the ncover node, i.e. between it and the <target> parent node that is as follows:

<if test="${not property::exists('satisfactoryCoverage')}">
  <property name="satisfactoryCoverage" value="90" />
</if>

This node makes sure that the satisfactoyCoverage property exists and is set to a default value of 90. Now, onto specifying it as a custom value when required:

<tasks>
  <nant>
    <buildFile>C:\BuildServer\BuildScripts\StandardDLL.build</buildFile>
    <buildArgs>-D:satisfactoryCoverage=85</buildArgs>

That's a snippet from the <project> node for a given project in the ccnet.config file. By specifying that build argument, the satisfactoryCoverage for that project will be 85%, rather than the standard 90%

Another "note to self" type entry, but, the article "Setting up CruiseControl.NET to be a Continuous Monitoring Server" from CodeProject looks quite ingenious.

There's the risk of trying to "use a hammer to put a screw in the wall" with an approach like this, but for a simple monitoring solution, CruiseControl would certainly seem to be a genius of a solution. Something I'm now going to have to consider in great depth!