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.

For reference, here's how you update your app.config appSettings using MSBuild Community Tasks XmlUpdate.  This example actually batches several app.configs that need changing.

I think most people probably know how to version C# projects by now, but for my own future reference here is how I'm currently doing it. 

In my project's csproj file I append the following VersionProject target to the BuildDependsOn project.  You could override the BeforeBuild target, but appending a dependent target is safer according to Sayed Hashimi.  The following goes directly into each of my csproj files:

 

The VersionProject target is a custom target in my global.targets MSBuild project file which gets included into my csproj file.  This target is using the MSBuild community tasks' AssemblyInfo task.

 

The great thing about this, I can reuse this target over and over again for each of my projects.  Some properties like the BuildVersion are set when running under CC.NET, others like CompanyName, Copyright are set once in the global.targets file as these don't change between projects.  By default my global.targets file will default the ProductName to the MSBuild project file name (minus the file extension), this of course can be overridden in any number of ways - including from CC.NET. 

The nice thing is, this will work when building from the command line with MSBuild.exe or from within Visual Studio.  This last point is important because we don't ever checkin the AssemblyInfo.cs source files to SVN (we set SVN ignore on these since they are autogenerated on every build) and most developers would like to checkout, open the solution, and finally CTRL SHIFT B.  Some OSS projects I've worked on require you to build from the command line first (to generate the AssemblyInfo.cs files) before you can build from Visual Studio; I believe this tends to confuse most .NET developers since most are so IDE dependant.

Another thing to note is that if a developer wanted to build a specifically versioned project from within Visual Studio all they would need to do would be to set an environment variable before starting Visual Studio, specifically: BUILDVERSION=1.0.0.1503.

Something I noticed today while cleaning up an MSBuild script is that there seems to be a direct correlation between the load time of bootstrapping MSBuild and your ItemGroups.  I noticed this because I have an ItemGroup that has an exclude to ignore any .svn folders on disk that I set at the parent folder level which contains a lot of files.

 

WHen I changed the above Exclude to $(ProjectDirectory)\Libs\**\$(SvnFolder)\** my build script load time was noticeably faster.  The interesting thing is, MSBuild doesn't count the loading of ItemGroups in its calculation of "Time Elapsed," running with either exclude setting produced identical Time Elapsed results - even though there was an obvious difference in run times.