Fear and Loathing

First post of the year and hopefully this is something useful. I think it is.

I'm currently doing a major automation-overhaul to our projects, trying to streamline everything. Part of this involves doing automated deployments of the projects to a location (say a file or web server) where a QA person can come along later and with the click of a button they can just launch an installer for any build of an application. This is very much structured like the JetBrains Nightly Build page you see here, but 100% automated for all projects using NAnt.

A lofty goal? Perhaps.

Anywho, the time to update the builds and page has come and I went hunting to see how I could do it (without having to write a silly little console app or something). To start with (and I'm not done here, but this works and is a model anyone can use) we have a basic XML file:

This contains build information for the project and will be transformed using XSLT into something pretty (and useful once I add more attributes).

The challenge is that we want to append an XML node to this file during the deployment process, which is kicked off by CruiseControl.NET. Sounds easy huh. There are a few ways to do this. First, I could write that console app or something and have it update some file. Or maybe it would even write to a database. Or... no, that's getting too complicated. The next thought was to use the ability to write C# code in NAnt scripts, but then that started to get ugly real fast and more maintenance than I wanted.

Then I turned to xmlpoke. This little NAnt task let's you replace a node (or nodes) in an XML file. Trouble is that's what it's designed to do. Replace a node or property. Not append one. After about 15 minutes of Googling (my patience is pretty thin for finding an answer on the 3rd page of Google) I realized xmlpoke wasn't going to be good enough for this. Someone had come up with xmlpoke2 which did exactly what I wanted (appended data to an XML file), but to date it hasn't made it into the core or even NAntContrib.

After looking at the XML file I realized I might be able to use xmlpeek (read some XML from a file) and combine it with xmlpoke (modifying it on the way out) and write it back to the file. Maybe not the most elegant solution, but I think it's pretty nifty and it gets the job done.

First we have our XML file (above) so I created a target in NAnt to handle the update to the XML file:

Step 1 - Use xmlpeek to read in the entire XML node tree containing the current builds:

Step 2 - Modify it by appending a new node with the new build info and saving it into a new property:

Step 3 - Write it back out to the original XML file replacing the entire XML tree using xmlpoke:

The result. Here's the updated XML file after running NAnt with our target task (and faking out the CCNetLabel that would usually get set by CruiseControl via a command line definition):

Now I have a continuously growing XML file with all my build numbers in them. Of course there's more info to add here like where to get the file and such but the concept works and I think it's a half decent compromise (to having to write my own task or more script). The cool thing is that you can even use it against a file like this:

This lets you start from scratch for new projects and start with build 1 (which will come from CruiseControl.NET). If the file didn't exist at all, you could even use the echo task or something like it to create the file, then update it with the task info above. Is it bullet proof? Hardly. It should work though and gives me the automation I want.

Well, I'm done for the day. That was a worthwhile hour to build this. Now I just have to go off and add in all the extra goop and hook it up to our builds.

Enjoy!

It's a party, last post of the year, let's see how we start off 2008.

Have a safe and happy evening!

The ALT.NET mailing list is pretty overwhelming. A week or so ago David Laribee proposed splitting it into various groups but that thread seems to have gone by the wayside. The list is the proverbial firehose of babble around ALT.NET (and everything else you can think of). Even longer ago was the notion of summing up the threads and pulling out the choice information into a digestable form. Of course this would mean work and well, it's much better to yap about it then do it.

Whilst doing my weekly ego surf, I came across a fairly new site, Alt.Net Pursefight! Of course it's anonymous, but it's a brilliant no-nonsense wrap-up on the goings on in the list. No thread is left unturned and no person is left without exposure. So hey, if you're looking for an unbiased opinion of what's going on check it out. It's like the Mini-Microsoft of the ALT.NET world.

Brilliant!

Sometime ago we were talking about file wrappers and testing these things on the ALT.NET mailing list. It's a rather boring task to test say a file system without actually writing files (which you might not want to do). Wouldn't it be nice to have a wrapper around a file system so a) you could forget about writing one yourself and b) you could throw something at Rhino mocks because you really don't want to test writing files.

I've put together a project implementing this and it's now released on CodePlex. It's composed of interfaces (IFile and IFileContainer) that provide abstractions over whatever kind of file or file container you want. This allows you to wrap up a file system (indivdual files or containers of files like folders) and test them accordingly. Concrete implementations can be injected via a Dependency Injection tool and you can sit back and forget about the rigors of testing file access.

There are 3 concrete implementations (found in FileStrategyLib.dll) that implement a file system (IFile), folders (IFileContainer), and zip files (IFileContainer using SharpZipLib). There's also a test project with a whopping 10 unit tests (providing 97% coverage, darn) included. More documentation and sample code is available on the CodePlex site.

You can check out the project here on CodePlex:
http://www.codeplex.com/ifilecontainer

1.0 is available and released under the MIT License. It contains the binary and source distributions. I'll check the code into the source repository later tonight.

Note that this is a very simple library concisting of 2 interfaces and about 50 lines of code. Of course being an open source project I encourage you to check it out and enhance it if you want. It's not the be-all system to get all kinds of information out but should get you started. It was originally written just for a simple system to create and add files to a folder and zip file but can be extended. Otherwise, consider it an example of having to wrap and test a system like a file system which you may run into from time to time.

Enjoy!

Update: Source code tree is checked in and posted now.

Having some fun with Ben Carey's Big Visible Cruise app. BVC is a WPF app that looks at CruiseControl (.NET, Ruby, and Java versions) and displays a radiator dashboard of the status of projects. As each project is building, the indicator will turn yellow then green if it suceeds or red if it fails. It's all very cool and I jumped all over this so we could have a visible display of our projects in the office.

Here's the default look that Ben provided:

I submitted a request to be able to control the layout and he reciprocated with a layout option (using skins in WPF). Here's the updated layout he provided:

I had a problem because with only a few (8 in my case) projects, the text was all goofy. The layout was all cool but I wanted something a little flashier and better to read, so some XAML magic later I came up with this:

Here's a single button with some funky reflection:

Okay, here's how you do it. You need to modify two files. First here's the stock LiveStatusBase.xaml file. This file is the base for displaying the bound output from the CruiseStatus for a single entry:

  <DataTemplate x:Key="SimpleStatusDataTemplate">
    <Border BorderBrush="Black" BorderThickness="1">
      <TextBlock TextAlignment="Center"
                 Padding="3"
                 Background="{Binding Path=CurrentBuildStatus, Converter={StaticResource BuildStatusToColorConverter}}"
                 Text="{Binding Path=Name, Converter={StaticResource BuildNameToHumanizedNameConverter}}" />
    </Border>
  </DataTemplate>

It's just a TextBlock bound to the data source displaying the name of the project and using the background color for the status of the build. Here's the modifications I made to make it a little more sexy:

    <DataTemplate x:Key="SimpleStatusDataTemplate">
    &lt;Grid Margin="3"&gt;
        &lt;Grid.BitmapEffect&gt;
            &lt;DropShadowBitmapEffect /&gt;
        &lt;/Grid.BitmapEffect&gt;
        &lt;Rectangle Opacity="1" RadiusX="9" RadiusY="9" Fill="{Binding Path=CurrentBuildStatus, Converter={StaticResource BuildStatusToColorConverter}}" StrokeThickness="0.35"&gt;
            &lt;Rectangle.Stroke&gt;
                &lt;LinearGradientBrush StartPoint="0,0" EndPoint="0,1"&gt;
                    &lt;GradientStop Color="White" Offset="0" /&gt;
                    &lt;GradientStop Color="#666666" Offset="1" /&gt;
                &lt;/LinearGradientBrush&gt;
            &lt;/Rectangle.Stroke&gt;
        &lt;/Rectangle&gt;
        &lt;Rectangle Margin="2,2,2,0"
          VerticalAlignment="Top"
          RadiusX="6"
          RadiusY="6"
          Stroke="Transparent"
          Height="15px"&gt;
            &lt;Rectangle.Fill&gt;
                &lt;LinearGradientBrush StartPoint="0,0" EndPoint="0,1"&gt;
                    &lt;GradientStop Color="#ccffffff" Offset="0" /&gt;
                    &lt;GradientStop Color="transparent" Offset="1" /&gt;
                &lt;/LinearGradientBrush&gt;
            &lt;/Rectangle.Fill&gt;
        &lt;/Rectangle&gt;
        &lt;Grid Margin="5"&gt;
            &lt;TextBlock TextWrapping="Wrap" TextAlignment="Center"
                       HorizontalAlignment="Center" VerticalAlignment="Center"
                       FontSize="32" FontWeight="Bold" Padding="10,10,10,10"
                       Foreground="Black" FontFamily="Segoe Script, Verdana"
                       Background="{Binding Path=CurrentBuildStatus, Converter={StaticResource BuildStatusToColorConverter}}"
                       Text="{Binding Path=Name, Converter={StaticResource BuildNameToHumanizedNameConverter}}"&gt;
            &lt;/TextBlock&gt;
        &lt;/Grid&gt;
    &lt;/Grid&gt;

&lt;/DataTemplate&gt;

I added a grid. The top rectangle is to define the entire area for each project (filling it in with the build status color) and the next one is the highlight (using a LinearGradientBrush) on the button. Then the TextBlock with the name of the project and it's build status gets filled in.

Now here's the stock BigVisibleCruiseWindow.xaml (the main window):

  <DockPanel>
&lt;Border DockPanel.Dock="Bottom"&gt;
  &lt;DockPanel LastChildFill="False"&gt;
    &lt;TextBlock DockPanel.Dock="Left"  Text="Big Visible Cruise" FontSize="16" FontWeight="Bold"  Padding="10,10,10,10"  Foreground="White" FontFamily="Segoe Script, Verdana" /&gt;
    &lt;Button DockPanel.Dock="Right" Content="Options..." FontSize="9" Margin="10" IsEnabled="False" /&gt;
  &lt;/DockPanel&gt;
&lt;/Border&gt;

&lt;Viewbox DockPanel.Dock="Top" Stretch="Fill"&gt;
  &lt;ItemsControl ItemsSource="{Binding}" Style="{DynamicResource LiveStatusStyle}" /&gt;
&lt;/Viewbox&gt;

</DockPanel>

The main window used a DockPanel and displayed some addition things (there's a button there for choosing options but it's non-functional). Here's my changes:

    <Grid>
        <ItemsControl ItemsSource="{Binding}" Style="{DynamicResource LiveStatusStyle}" />
    </Grid>

I just simply replaced the DockPanel with a Grid.

That's it! Feel free to experiment with different looks and feels and maybe submit them to Ben as he could include them in maybe a set of skins to use.

Note: You need to download the code from the repository as the 0.5 release Ben put out doesn't include the skins.

Just a quick update to TreeSurgeon as we've been working on some plans on updating the tool to have a more flexible framework for adding new tools and updating the output for newer versions of the .NET framework.

Donn Felker added VS2005 support so that's in right now. If you grab the latest from source control or download the latest ChangeSet from CodePlex here, you can get TreeSurgeon spitting out VS2005 and .NET 2.0 solutions. I'm just finishing up VS2008 support now and that'll be in the planned 1.2 release that we're coming out with shortly (probably by the end of the week). In addition, based on votes from the Issue Tracker (which we use as a Product Backlog) I'm looking to add MbUnit support so that will probably get into this release.

The UI is pretty ugly and could use some graphical loving. I'm not going to get all stoked about the UI right now but it does need something. I've been meaning to talk to Jay Flowers as he pinged me awhile back about hooking up and seeing if there's some crossover between CI Factory and TreeSurgeon. I'm not so sure as I still have yet to get my head wrapped around CI Factory (nothing against Jay but if I can't grok an install in 5 minutes I usually move on until I can come back and kill some time figuring out how it works). To me a CI Factory and TreeSurgeon is like Marvel vs. DC (or Mac vs. PC) as I'm not sure I see the synergies but we'll see where that goes.

We're also looking at doing some kind of plugin pattern for creating different type of tree structures. The original structure Mike Roberts came up with is great, but as with anything evolution happens and we move on. I personally use a modified structure that's based on Mikes, but accomodates different features. JP Boodhoo has a blog entry here on his structure, again, slightly different. In addition to the updates on the tree structure, we're looking at adding better support in the generated build file (and options for it in the ugly UI) for choosing what unit testing framework and how to compile using it (straight, through NCover, or NCoverExplorer). Again, some stuff is solid; others are up in the air but feel free to hook up on the forums here with your thoughts and ideas as we're always open to drive this the way you, the community, want it to go.

Like I said, you can grab the 2005 support right now from here and the 2008 support will be up on the server when we do the 1.2 release later this week.

Back to the grind.

If you're like me and dabble in everything, then you might have Visual Studio 2005 installed along with VisualSVN (a plug-in to integrate Subversion source control access with Visual Studio). The latest version of XNA Game Studio (2.0) now allows you to build XNA projects inside of any flavor of Visual Studio. Previously you could only use C# Express Edition, which meant you couldn't use any add-ins (the license for C# Express forbids 3rd party addons) which meant I couldn't use ReSharper. Anyone who's watched my XNA demos knows this peeves me to no end as I stumble pressing Alt+Enter to try to resolve namespaces or Ctrl+N to find some class.

Oh yeah, getting back to the point. If you've installed the latest Game Studio 2.0 you can now use it with Visual Studio 2005 (not 2008 yet). And if you've got the combo I mentioned installed (VS2005, GS2.0, and VisualSVN) you might see this when you create a new XNA project:

It's a crazy bug but I tracked it down via the XNA forums. Apparently there's a conflict if you're running the combination I mentioned. Don't ask me why a source control plugin would affect a project creation template. I just use this stuff.

Anyways, you can fix it with the latest version of VisualSVN (1.3.2). I was running 1.3.1 and having the problem, you may be in the same boat. Here's the conversation on the problem in the XNA forums; here's the bug listed on the connect site; and here's the link to VisualSVN 1.3.2 to correct the problem. All is well in developer land again as we enter the world of ReSharper goodness sprinkled with a topping of XNA.

Happy gaming!

Look like a new development community is forming, this time around XNA and Game Development. GameDevKicks.com uses the DotNetKicks code and has launched a new site for game development content. There's only 5 articles submitted, but looks like it's off to a good start. A good set of categories to start, a bit of a redesign from the typical DotNetKicks look and feel (something like a cross between Digg and DNK) but it's just starting off.

So if you're into the game development scene feel free to help out and see if this kicks community can grow and prosper. Check out GameDevKicks here and give a whirl.

More game development news to come shortly from your friendly neighborhood SharePoint-Man.