Draggy bags...

You know those bags with wheels and handles! Hate them.  Crowded places like railway stations and airports where we are all herded through like sheep are annoying enough without having to trip over the little draggy bags - suitcases are easy to avoid, but the little ones just get under your feet!!

CruiseControl.NET installation in 7 easy steps

I often find people are intimidated by CruiseControl.NET. One of the phrases I have heard before is that it is "only really sensible for new projects" - the explanation behind this usually being that it is too difficult to set up for existing solutions.  This guide is designed to show how easy it is to get started on any .NET solution, no matter where in the development phase. 

The primary goal of this guide is simply to create a nightly build of a project maintained in Visual SourceSafe 2005 with CruiseControl.NET - one of the simplest configurations you can imagine. Those of you doing continuous integration will already recognise this as the first in many baby step's that can be taken to improve existing process using CruiseControl.NET (hopefully the subject of a future article). Those of you who want more information on what continuous integration is and can do to help may find these articles useful:



Step 1 is to download and install the CruiseControl.NET application from http://sourceforge.net/projects/ccnet/ - pretty straight forward!  The version dealt with in the post is 1.3 which was released 21/06/2007.

Step 2 is to get the project(s) buildable using MSBuild from the command line, this is just a simple check to make sure the projects work! eg:

	msbuild c:\test\app.sln /t:Clean /p:Configuration=Debug

Step 3 create a VSS user specifically for CruiseControl.NET to log in as.

Step 4 configure the ccnet.config file which is found in the installation directory (default Program Files\CruiseControl.NET\server).  Simple config will require the a project with sourcecontrol section, an interval trigger and an msbuild, eg:

  <project name="TestCCNET">
    <sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
      <executable>E:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
      <intervalTrigger seconds="60" />
        <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
      <xmllogger />

Don't be frightened - when you actually look at it - there is very little required, just the source safe details and solution location!  Note that we have set the build interval to 60 seconds - this will allow us to test the configuration easily in the next step.

Step 5 download the XML Logger for MSBuild from http://ccnetlive.thoughtworks.com/MSBuildXmlLogger%2DBuilds/ and copy to the the project workingDirectory (in the example above this is set to E:\work\LocalVSS\TestProject). This logger is used by CruiseControl as described in http://confluence.public.thoughtworks.org/display/CCNET/Using+CruiseControl.NET+with+MSBuild.

Step 6 is to check the configuration setting using the command line tool.  The ccnet.exe command line tool can be found in the server directory beneath the install directory (default Program Files\CruiseControl.NET\server).  The console will run the settings and attempt the build every 60 seconds (as configured previously).  The console output is good and it should not take you long to get a basic configuration like the example above working.

You can use the Web Dashboard to force through a build (so you don't need to make a change in SourceSafe!). The Web Dashboard will be available at http://server/ccnet and the Force button is available under the admin header for each server.

Step 7 finally change the ccnet.config to replace the 60 second interval trigger with a schedule trigger eg:

<scheduleTrigger time="23:30" buildCondition="ForceBuild" name="Scheduled">

Which again is fairly straight forward and will run the build every day at 2330.

So that's it CruiseControl.NET up and running to run nightly builds in 7 steps! You can now use the service rather than the command line to listen for builds, and you can use the web dashboard on the CruiseControl.NET server (http://server/ccnet) to see status of builds and force builds (when the service is running).

Clearly there is loads more that CruiseControl.NET can do (notably run your unit tests) all of which you can find using the ThoughtWorks documentation site


Debugging ASP in Visual Studio 2005

I recently had to go back in time, and debug some traditional/classic ASP.  The fact that the code was relatively nasty is pretty much irrelevant, having the capability to debug and edit in my familiar Visual Studio 2005 IDE made the job a little easier to bear! Here are the steps to enable ASP debugging in studio...

Firstly you need to Enable Server Side ASP script Debugging in IIS - this can be done at the web site level or at the virtual directly level.  For the web site go to the Home Directory Tab on properties page, and for the Virtual Directory go to the Virtual Directly tab on the properties page.  From this tab select the Configuration button under Application Settings.  On the Configuration screen select the Debugging tab and check the Enable server-side ASP script debugging.

The quick way to get to the point of debugging with all code in the IDE is to open the Web site in Visual Studio (File, Open, Web Site).

If you are using server side JavaScript then you can use the debugger statement in code to force debugging - you are offered the choice of debug tools...  Or you can attach to the running process using Debug Attach to Process.  On XP the ASP process runs under a process dllhost.exe under the IWAM user.  Clearly you need to ensure you attach to the correct process, fortunately the IDE gives a nice visual warning if you get the wrong one.


Either way you do it you will be shown a warning when attaching to the process


And once you attach you can step through the code as normal!

In the code I was looking at there was another interesting feature.  At some point during the difficult and painful life of this product the page Language had managed to get set to JScript.Encode (even though the code was no longer encrypted) which blocks debugging.

Angular bind ! of Boolean property

It seems like a trivial task. In an Angular app change a checkbox that manages the Deleted ‘soft delete’ property to invert and show as an Active property.

So the naive approach is just to try and change the two way model binding to ! the boolean value – something like:

<input name="IsDeleted" type="checkbox" [(ngModel)]="!input.IsDeleted">
<input name="IsDeleted" type="checkbox" class="form-control" [(ngModel)]="!input.IsDeleted" [disabled]="!canWrite">

Frighteningly this very nearly works! But you will find the behaviour of the model set is not correct, requiring two clicks on the check box – to be fair the docs do say to only set a data-bound property. So what do you do?

To stick with the two way data-binding syntax you could add getter/setter accessors on the component itself:

get isActive() { return !this.input.IsDeleted; } set isActive(newValue: boolean) { this.input.IsDeleted = !newValue; }

then use these as the target of the two way data-bind expression:

<input name="IsDeleted" type="checkbox" [(ngModel)]="isActive">

Personally I think a more elegant is to use the one way binding to display the inverted value and the event syntax (for the checkbox the change event) the set the inverted value:

<input name="IsDeleted" type="checkbox" class="form-control" [ngModel]="!input.IsDeleted" (change)="input.IsDeleted=!$event.target.checked" [disabled]="!canWrite">
<input name="IsDeleted" type="checkbox" [ngModel]="!input.IsDeleted" (change)="input.IsDeleted=!$event.target.checked">