Recently in Nant 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!

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!