When extending existing MSBuild targets, its often wise to append to the build target properties rather than override an existing target.  Its appears there's no way to override a target and then call the base target, this really annoys me because often I just want to add additional behavior to the existing target.  It seems the way around this is to add a property or itemgroup to the DependsOn attribute of a target, even if the itemgroup is empty, it just leaves a place open in the future for extensibility.  Here's in example from my shared targets file:

<Target Name="CreateDiskImage" DependsOnTargets="@(BeforeDiskImage);Build">

Now in some script which imports this targets file I can just declare one or more BeforeDiskImage items and they will automatically get run before the CreateDiskImage target.  If you look at the the MS providded targets files you will see this is done in a similar manner all over the place.  Here's a good reference for the C# targets you can hook into:

http://blogs.msdn.com/msbuild/archive/2006/02/10/528822.aspx

Yesterday I came to the realization that I'm not paid to write code anymore, I'm paid to delete code.  If my employer was paying me by lines of code written, I would owe my employer tens of thousands of dollars just for the past few months of work.  Sure, I've written a few lines of code here and there to refactor our codebase, but even with adding unit tests (that were non-existent before), I've always managed to reduce the size and complexity of the code, because less code is more.

In most cases its just dead code and completely useless comments that I get to delete in effort to reduce noise.  In one memorable instance I deleted over 3000 lines of code from a DAO class!  3000 lines!  If the average programmer writes 10 lines of code per day, then I just deleted almost a years worth of work in about 10 minutes.  Perhaps I rationalized that a bit.  I'm pretty sure most boilerplate ADO access code is cut and paste anyway, but regardless, I must say, very satisfying.

In another instance I reduced the number of assemblies our installer deploys by half, and cut the size of the main executable down by 4MB (from 6MB) by deleting unused legacy resources and being smart in the way the remaining resources are handled.  It appeared that more a more assemblies were added to our installer, but none were ever removed, even when the need for those assemblies had long past.

I'm comfortable in my new deletor position because every line of code I delete is one less to worry about.  After all I just want to see what's important in front of me and get rid of the noise - thank you very much.

-- Thank you ReSharper, because without you I could not be Sneal, aka the deletor.

Sometimes its just so hard to do the simple things with Windows, like unzip files without a 3rd party DLL.  After banging my head on this for a couple of hours I finally figured out a way to do it using Windows PowerShell and the Windows XP ZIP explorer extensions through the Shell32 COM interface.

function UnzipFile([string] $zipFile, [string] $destinationFolder)
{
    if(test-path($zipFile))
    {
        $shell = new-object -com Shell.Application
        $srcFolder = $shell.NameSpace($zipFile)
        $destFolder = $shell.NameSpace($destinationFolder)
        $items = $srcFolder.Items()
        $destFolder.CopyHere($items);
    }       
}

Hooray!  I now have both of my LCD's working in Ubuntu, ala "TwinView."  I attemped to use the nVidia confiuration utility, but ended up needing to manually edit my xorg.conf file to get the right settings.  I think the utility would have worked if my secondary LCD was connected using a DVI cable, but unfortunately it only supports VGA so I think the resolutions were not getting auto-detected properly.

For future reference, here's the relevant portions of my xorg.conf file with the dual monitor stuff in bold:

Section "Monitor"
    Identifier     "Acer AL2216W"
    HorizSync       30.0 - 82.0
    VertRefresh     56.0 - 76.0
    ModeLine       "1680x1050" 146.2 1680 1784 1960 2240 1050 1053 1059 1089 +hsync -vsync
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "nVidia GeForce 8600 GT"
    Driver         "nvidia"
EndSection

Section "Screen"
    Identifier     "Default Screen"
    Device         "nVidia GeForce 8600 GT"
    Monitor        "Acer AL2216W"
    DefaultDepth    16
    Option         "UseFBDev" "true"
    Option         "RenderAccel" "true"
    Option         "TwinView"
    Option         "MetaModes" "1280x1024, 1680x1050; 1024x768, 1280x1024"
    Option         "TwinViewOrientation" "LeftOf"
    SubSection     "Display"
        Depth       16
        Modes      "1680x1050" "1280x1024" "1280x960" "1280x800" "1152x864" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection     "Display"
        Depth       24
        Modes      "1680x1050" "1280x1024" "1280x960" "1280x800" "1152x864" "1024x768" "800x600" "640x480"
    EndSubSection
EndSection

I finally got 1680x1050 resolution working on my GeForce 8600 GT and Acer 22" widescreen LCD.  I used the Wubi installer for this which made it super easy to dual boot with Vista, however on the login screen I kept getting an "Out of Range" error using the built in OSS nVidia (nv) drivers.  After some reading I found that I would need the nVidia provided binary drivers to get dual monitors working anway, so I thought I would see if this would allow me to run at the native resolution of my monitor.  Of course I found that my particular video card, GeForce 8600 GT, was not supported by the nVidia binary driver installer.  I ended up doing a manual install of the drivers which actually worked, unlike the untold number of xorg.conf edits I made previously.

1. Download the NVidia binary drivers from their website.
2. Change to command line (CTRL ALT F2), and shutdown your display manager: sudo /etc/init.d/gdm stop
   
3. Install the dev libc libraries since no precompiled libs exist for my Ubuntu version.  sudo apt-get install libc-dev.
4. Install the drivers: sudo sh NVIDIA* -k (run this from the location you downloaded the binary drivers too).
5. Follow the install instructions, when prompted allow the installer to configure your xorg.conf file.
   

I finally figured out why I was having problems specifying sub-folders (other than trunk) in my ccnet.config SVN source control provider trunkUrl element.  After toying around with svn log (which is what CC.NET uses to find changes), I discovered it only worked on some of the folders in our repository.  As it turns out you must specify the folder ensuring you are respecting letter case.

This does not work: svn log http://mysvnserver/svn/gp/trunk/commons

This does work: svn log http://mysvnserver/svn/gp/trunk/Commons

Notice the upper case C on the second line.  I'm sure this is probably documented somewhere in the SVN docs, but I don't remember seeing it.  The other possibility is that Apache is causing the problem.  Perhaps on Monday I'll care enough to look at the docs.