FastForward.NET: Error Handling

Oh No, It’s Crashed!

It’s hard building real-world software. Not that writing software is hard, no it’s the “real-world” part that is hard! Why? Because the real world is messy!

I’m not talking about a little bit of mud or slime that can be easily wiped off, no, I’m talking about your kids haven’t cleaned their bedrooms in a year and they can’t that check they were supposed to bank three months ago messy. Times that by a hundred kids, in different countries, some of whom don’t even understand you!!

Not that I’m advocating sloppy coding, but sometimes, no matter how beautiful the code is, things just break. For no apparent reason (yes, I know it worked on your machine when you wrote it.) That’s why someone coined the term defensive programming. And like all developers, my code needs defensive code just as much.

Hence, in the next release I’ve added some error handling code.

You Mean It Isn’t Perfect?

Yes, FastForward.NET isn’t perfect

So I have added a generic handler for all unhandled exceptions (yes there are place were I expect problems and have error handling in place.) If one of these errors occur you’ll get a message like this:

This tells you there was an error, it logs the details and tells you where and then advises shutting down the application. I could have been mean and just killed the application, but I’ll give you the choice (it is highly recommended though!)

What’s in the Log?

The reason I generate the logs, is it is nice to get some data on what caused the crash. So, here is an example log:

  1: <?xml version="1.0" encoding="utf-8"?>

  2: <errorLog>

  3:   <environment time="2009-08-19T19:23:00.2808000+12:00"

  4:                os="Microsoft Windows NT 6.0.6001 Service Pack 1"

  5:                processors="2"

  6:                clr="2.0.50727.3074" />

  7:   <error type="System.Exception">

  8:     <message>Hey, you've broken something!</message>

  9:     <stack>

 10:       at FastForward.Monitor.Plugins.BuildVisualisationDisplay.OnMouseDown(MouseEventArgs e) in C:\Open Source\FastForward.NET\trunk\project\FastForward.Monitor\Plugins\BuildVisualisationDisplay.cs:line 136

 11:       at System.Windows.Forms.Control.WmMouseDown(Message&amp; m, MouseButtons button, Int32 clicks)

 12:       at System.Windows.Forms.Control.WndProc(Message&amp; m)

 13:       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&amp; m)

 14:       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&amp; m)

 15:       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

 16:       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&amp; msg)

 17:       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)

 18:       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)

 19:       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)

 20:       at System.Windows.Forms.Application.Run(ApplicationContext context)

 21:       at FastForward.Monitor.Program.Main() in C:\Open Source\FastForward.NET\trunk\project\FastForward.Monitor\Program.cs:line 46

 22:       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)

 23:       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)

 24:       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()

 25:       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)

 26:       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

 27:       at System.Threading.ThreadHelper.ThreadStart()

 28:     </stack>

 29:   </error>

 30: </errorLog>

As you see, there’s nothing confidential So it would be nice if you get one of these, if you could post it in the error report on Trac.

And of course, feel free to add any additional information you think would be helpful. I promise I will try to resolve any issues as fast as possible.

Why Targets?

This post is the answer to a question I was asked recently.

The Question

Looking at the add server window, there is an address field and a target server field:

The question was why are both necessary?

The Answer

The answer to this question lies in the way the different components of CruiseControl.NET (CC.NET) communicate. The following picture shows the components and their interactions:

What we are really interested in monitoring is the CC.NET. However, the server is not always what is connected to. It is only a direct connection if .NET Remoting is used (or a custom protocol). If someone is connecting via the web dashboard, the address they enter is the address of the dashboard, not the CC.NET server.

Since we want to monitor the actual server, not the dashboard, the target server field is required. This tells the dashboard that although it has received a request, the request for for an actual CC.NET server and needs to be passed on.

Now, in CCTray this field is not needed. But then a lot of the functionality in CCTray is only available for a .NET Remoting connection – they will fail on a HTTP connection. And this is exactly the reason why they fail – the dashboard guesses which server the request should be sent to, and it can’t always get the right server!

Related Questions

This leads to a few other questions:

1: What is the target server for a dashboard connection?

In the dashboard, it displays the available target servers:

The available servers are listed on the left under the heading “Servers”.

2: What is the target server for a .NET Remoting connection?

Currently this is ignored, but in future CC.NET may handle routing to other servers (i.e. in a farm scenario). Therefore, this should be left as “local”. This will tell CC.NET that the request is for the local server and should not be passed on.

3: Is there a way of listing the servers in the monitor?

At the moment CC.NET does not provide a list of possible target servers. This needs to be added to CC.NET first (i.e. in the dashboard) and then I can add the listing to the monitor.

This is on the to-do list, but first I need to resolve some of the other issues in FastForward.NET.

4: If I want to monitor multiple CC.NET servers that are on one dashboard, do I need to add them individually?

Yes. FastForward.NET monitors the individual servers – not the dashboard.

In future I may add the ability to monitor a dashboard instead of the individual servers – but this means the interactions that are currently provided will be more limited (i.e. to what is allowed by the dashboard).

FastForward.NET: Plug-ins

An Exciting New Area!

One of the new areas that I am excited about for the FastForward.NET monitor is plug-ins. In CCTray, new functionality was added to the core application – whether or not people wanted it. This led to an increasing number of dependencies for CCTray (SpeechLib, Growl, cm17a, etc.) If you didn’t want the functionality, tough! Additionally, these dependencies (plus some other issues) meant that CCTray would only work on a Windows machine

FastForward.NET has an extension framework to allow for new, non-core functionality. This allows user to pick and choose what they want, and also means there will be a smaller set of dependencies. Additionally, plug-ins can also influence the UI – making it easy to add new nodes to the explorer or new tabs to the main window!

In this post I will cover some of existing plug-ins I have added. This is both to document how they work, and also provide some details on what can be done.

Configuring Plug-ins

All the configuration for plug-ins is done in the plug-ins tab of the settings dialog. This includes both adding or removing plug-ins, and per-plug-in configuration.

To add a new plug-in, you need to go to this tab:

Click on the add button, and you will be prompted to select a plug-in:

The dropdown lists all the available plug-ins, plus allows you to import new plug-ins (more on this later):

In the screen shot, you can see there are five plug-ins already developed . Four of these are “core” plug-ins, in that they exist within the main executable, while the fifth is an example of an “extension” plug-in – one that is outside of the core executable.

Let’s take a look at these plug-ins, what they do and how they can be configured.

Note: This is still very early days for the plug-ins, I expect they will continue to change and improve over time.

System Tray Notifications

Unlike CCTray, the FastForward.NET monitor does not offer any in-built notifications. One of the original notifications in CCTray was the system tray notifications – and so these have been added as a plug-in for the monitor.

This plug-in works in the same way as the system tray notifications in CCTray. It adds a little icon to the system tray which shows whether any builds are in process or not. Additionally, it will display pop-up notifications for various events – at the moment these events are the start and end of builds.

The following configuration options are available:

These are all pretty simple – it just states when the notifications should be displayed.

Security Information

With CruiseControl.NET 1.5.0 security has been added. The only problem is the only place this is visible is in the dashboard. This plug-in allows some of the security information to be displayed in the monitor.

This plug-in will add a node to the server tree – to display the users – and add a new tab – to display the audit log:

Of course, the server needs to be configured to have security, and the logged in user needs to have the valid security permissions, otherwise these items will be empty (like above).

Currently, the only configuration option for this plug-in is whether to display the audit log tab or not.

I’m still planning on adding extra details to this plug-in, so feel free to send any suggestions on how I can improve it.

RSS Feed Display

It is possible to configure CruiseControl.NET to generate a feed for projects. This plug-in provides an alternate way of viewing these feed. Enabling this plug-in will add a new command – View RSS Feed:

Clicking on the option will open the feed in a new window:

Otherwise, this just works like a standard feed (except without needing to go through a web server.)

There are no configuration settings for this plug-in.

Build Visualisations

I’ve already talked a little bit about this one before, but basically I wanted to test the plug-in infrastructure and so came up with this plug-in. It provides an alternate way of displaying projects (similar to BVC):

There are a few different configuration settings – mainly around changing the colours:

Currently you can only change background colours, but if there is enough demand I will also add the foreground colours. But like I said, this was just an opportunity for me to play around with some GDI+

Speech Notifications

The final plug-in is an extension plug-in – you need to copy the DLL into the plug-ins location or directly import it. The reason for this is simple – this plug-in relies on WPF, which is certainly not available in Mono (not now, maybe never).

Rather than add a dependency on SpeechLib, this uses the WPF managed interface. Like its name says, this plug-in will speak build notification events.

In many ways this is similar to the system tray plug-in – except you can choose the voice (if there are multiple voices installed):

That’s All…For Now

These are the plug-ins I have developed to date. I do have some plans for more, and I will also cover the inner workings of plug-ins in a future post so other people can write their own plug-ins

Have fun…

FastForward.NET: Projects

A Quick Recap

This is the third in a series of posts on how the new FastForward.NET monitor works. In my previous posts I covered the following items:

• Main Window
• Extra Information
• Initial Setup

In this post I will look at how a user can interact with a CruiseControl.NET server.

Currently there are four ways a user can interact with the server:

• Force a build
• Abort a build
• Start a project
• Stop a project

I have removed the “volunteer to fix build” functionality for the moment, as I think it needs a bit more design to how to get it working properly!

Project Commands

Carrying on the standard for FastForward.NET monitor, there are four ways to execute any of the above commands. The first two approaches are fairly obvious:

There is the new toolbar – this has the four buttons on it. These buttons will always be displayed, no matter what tab is being displayed or which projects are selected.

The next, is the dropdown menu:

In CCTray the menus were very limited (and other than the settings menu, not very useful). In the FastForward.NET monitor all of the commands are also available in the menu system. Again, like the toolbar, these commands will always be visible.

When a command is selected from either the toolbar or the menu, the monitor will check to see which projects have been selected, and then send the commands to those projects. If there are no projects selected, then an error will be displayed:

The final two ways of triggering a command are both contextual. These are accessed by either right-clicking on the monitor explorer:

On on the projects grid:

Both of these content menus are context-sensitive. Depending on the different project states, different menu options will be displayed. This only applies to the four project commands – the other commands are always displayed.

There is one other “major” change to CCTray – multiple projects can be selected! In the above screen shot there are three projects selected. When multiple projects are selected, the same command will be sent to all of them.

Build Parameters

The FastForward.NET monitor also allows build parameters. Since multiple projects can be selected, this interface is slightly different:

In this screen shot we have the parameters for each of the projects listed. If cancel is clicked, then all of the build requests will be cancelled – it is an all or nothing approach.

In CC.NET each parameter can have a description associated with it. This is displayed in two different ways:

The display panel down the bottom shows the description of the currently selected item. Additionally, mousing over any other item that has a description will display the description in a popup.

Finally, the parameters display obeys all the validation rules that have been set for the parameters:

Clicking on ok will send the build commands to the server (or servers), along with the correct parameters. It won’t send the wrong parameters to the wrong project!

In Conclusion

Looking back, sending commands for projects hasn’t changed that much between CCTray and FastForward.NET, mainly making the commands more consistent and accessible, plus a couple of usability tweaks.

However, this does lay the groundwork for new functionality in the future

FastForward.NET: Extra Information

Last Time…

In my last post (read it here) I wrote about what information is available in the main display of the FastForward.NET monitor. As well as this information, there is also additional information a button click away.

In my last post, I had the following screen shot:

There is a toolbar sandwiched in-between the menu bar and the explorer/tabs. This provides a quick and easy way of accessing functionality. As well as the toolbar, the commands are also available in the menu (although they are split between View and Project) and as context menu commands in both the projects grid and the explorer.

In this post, I’m going to cover the last four buttons – the “view” commands.

Viewing the Website

CruiseControl.NET contains a component called the web dashboard. This contains a lot of additional data that is not available in either CCTray or the FastForward.NET monitor. Sometimes, it is necessary to view this information. In CCTray this opened up the web site in the default browser. FastForward.NET offers the same functionality, but in a slightly different way.

The first “view” command is the “View web page” command. This will open a new window containing the web page:

This is literally the web page as a browser would see it – the only difference is it is still within the FastForward.NET context. A user can do the standard navigation around the site, and if they want it in a separate browser instance, they can open the instance by clicking on the last button in the toolbar.

Viewing the Build History

This is something that is new to the FastForward.NET monitor – CCTray does not offer this functionality (although it is available in the dashboard). Clicking on the “View build history” command (the second button) will display a list of all the builds:

In this window, a list of all the previous builds are displayed on the left. This includes the date/time of the build, the label (if successful) and the outcome of the build. On the right-hand side is a more detailed display of the selected build.

In the screen shot, there is the build summary. This contains the high-level details on the build, plus any modifications. This report has one advantage over the dashboard version – it groups the modifications into change sets:

As well as the details display, it is also possible to add additional build templates, such as an MSBuild template:

Another advantage that the monitor has over the dashboard, is changing builds will remember the last selected template:

This makes it nice and easy to scan through the builds and see at a glance what has changed.

Now, at the moment there are not many templates – I still need to go through and develop them. It is possible to use the templates from the dashboard, as it is the same underlying data and technology (i.e. an XSL-T transform). However, due to the differences in licenses between CruiseControl.NET and FastForward.NET I am redeveloping the templates.

Viewing the Current Status

The FastForward.NET monitor also allows a user to view the current status of a build:

This is very similar to the current status display in CCTray. The main difference is the progress is on the left hand side of the display – and it will actually show the progress of the currently selected item (CCTray only shows a general colour). In the above screen shot, the build is a quarter of the way through. In the next snapshot we see the selected item has completed:

Unfortunately there is a bug in the current CruiseControl.NET code where incorrect statuses are reported for child items of pending items. When I go and fix that bug then the display will show the correct status for pending items as well.

This view also contains one additional data field not in CCTray – the elapsed time. This is the amount of time a task has been running, if it is still running, or the total run time for the task if completed.

Viewing Packages

Like CCTray, the FastForward.NET monitor offers the ability to download packages:

This pretty much works in the same way. The display shows the package name, which build it was generated for and the date/time of generation. It also shows the number of files in the package and the package size. When the user double-clicks on the package, it will prompt them for a file name and location and then download the package.

Conclusion

That’s it for the extra information that the monitor provides. I am thinking of adding some additional information to the monitor over time (like graphs, additional queue information, etc.), but this is enough for an initial release.

It is possible to extend the monitor to include additional information via plug-ins. In my next post I’ll show some of what can be done. Stay tuned…

FastForward.NET: Main Window

Some More Details

One of the objectives that I aimed for in developing the FastForward.NET monitor was to provide more quality information on what is happening to the CruiseControl.NET servers.

CCTray showed what is happening to projects, with a little bit of information on the underlying queues. This is mainly historical, as CCTray was originally developed when CruiseControl.NET did not have queues. Unfortunately the way queues were added to CCTray gives the impression that they were more of an after-thought than a first class citizen. FastForward.NET aims to rectify this, along with some other glitches.

Project Details

At its heart, CruiseControl.NET is all about building projects. So any client needs to display project information. The FastForward.NET monitor has an entire grid just devoted to project information:

This grid contains a number of columns of information. From left to right, these columns are:

• Server: This is the local name of the server (see my earlier post on configuring servers).
• Project: This is the actual name of the project.
• Category: An optional category that the project belongs to.
• Activity: This is the current activity of the project. Currently this can be one of the following: Sleeping, Stopped, Pending, Building or CheckingModifications. This status comes from the server, the monitor just displays it.
• Detail: Any messages for the project – more on this below.
• Last Build Label: This is the label of the last successful build.
• Last Build Time: This is the date and time that a build was attempted. The previous column only shows the result of a successful build, this column shows any build – failed or successful.
• Status: This is the current status of the project. Again this comes from the server – the current statuses are: running, stopped, stopping.

The details column contains a mix of different data items. If there are any messages from the server (e.g. build breakers, failing tasks, etc.) it will be displayed here. Additionally, the next build check time will be displayed here. This is when the project will next be checked for any modifications – again this is information from the server.

This information is only displayed when the project is either sleeping or stopped. When a project is in a build state, this information is removed:

In this example, the FastForward.NET project is checking for modifications. As you can see, the details are removed and a yellow bar is displayed instead. A similar yellow bar is also displayed when the project is pending (i.e. waiting in a queue).

When the project is building, the completion status is displayed instead:

This is done both textually (25% completed) and graphically (the green bar in the background). As the build progresses, both the text and the bar are updated. Hopefully this will provide a nice easy way to see what is happening to the projects at a glance!

Queue Details

As I write earlier, queues are now treated as an integral part of the monitor. Whether people use queues in CruiseControl.NET or not, they are still there under the hood. The monitor now shows what is happening for these queues.

The first grid of details is similar to the projects grid in that it shows queue-specific information:

From left to right, the following columns are displayed:

• Server: The local name of the server.
• Queue: The name of the queue on the server.
• Number of Requests: How many requests are currently on the queue. The first request on the queue will be the active request, any additional requests are pending.
• Current project": This is the project that is currently building for that queue.

As you can see, this provides the main details on the queues. However, there is one important detail that is missing – which projects are pending for each queue. This is handled by the next tab – All Queue Requests:

Since a queue can have multiple pending requests, I have put these in their own grid. If there are no pending requests this grid will be empty. But as requests are added, the grid is populated.

Again, from left to right, the following columns are defined:

• Server: The local name of the server.
• Queue: The name of the queue the request is on.
• Project: The name of the project the request is for.
• Status: The current status of the project – this is the same as the activity for a project.
• Time Added: The date and time the request was added to the queue. This provides an indication of how long a request has been waiting.

As you can see, this view provides a bit of a combination of details from the project and queue grids, but hopefully it provides sufficient details on what is happening to the queues.

Some Funky Pictures

One of the key requirements for the Monitor is extensibility (more on this in a future post). However, just to show what is possible with extensions, I have added a “visualisation” of the projects:

This was more my playing around, but as you can see, it provides a very easy to look at image of what is happening to the different projects. And yes, I got the idea for this from BVC

The good news is this was very easy to do, and very easy to add to the monitor. I’ll write another post in the future on plug-ins and I will cover this in more detail then.

Monitor Explorer

As I stated earlier, I think the queue display in CCTray looks like more of an after-thought. But, I do like the concept of having a overall at-a-glance view of a server. To achieve this, I took the queue display from CCTray and expanded it:

This display contains the queues, like CCTray, plus their requests. It also includes the projects that are on each server. This enables us to see quickly and easily what state each project and queue is in for one or more servers.

And as you can see in the last screen shot, the build requests are also displayed under each queue.

Finally, the monitor explorer is extendable as well. I haven’t shown it here, but a plug-in can add additional server items if desired (more on this to come!)

Synchronisation

One of the items that I dislike about CCTray is the disconnect between the queues display and the main project grid. In the FastForward.NET monitor, this has been resolved. All of the information comes from a single source – so any of the views (explorer, project/queue/requests grids, etc.) show the same information at the same point in time:

In this view we can see both the monitor explorer and the projects grid has the same information. And in the next view we see the build requests view is the same as the monitor explorer:

Summary

This post has covered the information that is displayed in the main tabs of the monitor and the new monitor explorer.

In my next post I will cover some of the extra information that is available. Stay tuned…

FastForward.NET: An Initial Setup

Introduction

When FastForward.NET Monitor is initially installed, it will be in a “blank slate” state. There will be no servers configured, no templates or plug-ins loaded, etc. Basically, it will be pretty useless.

The first task in making the Monitor useful is to configure it. This tutorial will go through the steps necessary to configure the Monitor to display the projects for a server, plus show tray notifications of changes.

Initial State

The following is a screen shot of the initial state of the Monitor when it is first run:

There are no projects listed in the “All Projects” tab, and the Monitor Explorer tree is also empty. I haven’t shown it, but the other tabs are also empty.

To change this, go to File –> Settings:

This will open the settings dialog. The first tab (Servers) shows all the configured servers, plus has options for manipulating these servers:

The second tab (Settings) shows the general settings for the Monitor:

The third tab (Templates) shows the loaded templates. These templates are used in the build history for generating different reports. As well as displaying the templates, this tab allows us to add and remove templates:

The final tab (Plug-ins) shows the loaded plug-ins, plus allows us to add, remove and configure the plug-ins:

As you can see, the initial state of the Monitor is pretty empty – no servers, templates or plug-ins have been configured! Let’s go through the process of adding a plug-in and a server.

Displaying Build Notifications

In its default state, the Monitor does not display any notifications. In order to display notifications, we need to add a plug-in that displays notifications.

We want to add system tray notifications. This will add a little icon to the system tray (normally in the bottom-right corner of Windows). When a build starts or finishes it will pop up a balloon notification.

This is done in the Plug-ins tab. Click on the “Add Plug-in” button. This will display the add plug-in dialog:

Clicking on the drop down list will display all the available plug-ins:

Since we want to add system tray notifications, we will select this plug-in. This then brings up a description of the plug-in:

Clicking on “Ok” will then load the plug-in to the list of loaded plug-ins:

Note, this will not actually “load” the plug-in into the Monitor. This occurs when the “Ok” button is clicked on the settings dialog. This will close the dialog and update the monitor with any changes.

Most plug-ins offer additional configuration options. These can be accessed by selecting the plug-in and then clicking on the “Configure Plugin” button. This then opens a configuration dialog for that plug-in. For example, this is what system tray notifications shows:

And that’s it for adding and configuring plug-ins. The application takes care of everything else for us.

Adding and Configuring a Server

Since the entire purpose of the monitor is to watch one or more CruiseControl.NET servers, let look at what is required to add and configure a server.

In this example, I will add a server using .NET Remoting as the transport. This will be a simple 1.5.0 instance of CruiseControl.NET.

The starting point for this example is the Servers tab of the settings dialog. Click on the “Add Server” button. This will display the Add Server dialog:

 

This gives a number of basic connection settings. The first field, Address, is the address of the target server. This is generally a URI (e.g. tcp://somewhere, http://somewhere/ccnet, etc.) but it can also just be a server name. If it is just a server name, it will assume that it is using tcp:// as the protocol.

Transport allows the user to select which transport to use:

The (Default) option will use the protocol in the address to determine the transport mechanism used. Use this drop down if you need to specify a different transport from the address protocol.

The Connection to pre-1.5.0 server check box allows connection to an older style CruiseControl.NET server. In theory this will use .NET Remoting, but there are no guarantees. I would only use this option together with HTTP.

The final option is Target Server. This is used for connecting to a remote server that in turn connects to multiple CruiseControl.NET servers (e.g. the dashboard). At the moment this is an experimental feature in the underlying Communications Client, so I’m not sure how well it works.

Once all the settings have been added, click on the Ok button. This will then attempt to validate the server:

Monitor will attempt to connect to the remote server and retrieve its version number (if possible). If this process works, then the server configuration is valid, otherwise the details you entered were incorrect.

If this works, the Server Configuration dialog will appear:

 

This is the same dialog that is displayed when the “Configure Server” button is clicked in the Servers tab. This allows the user to configure additional settings for a server (it is not possible to change the transport settings for a server).

The display name is a name that will be used locally within the Monitor. If this name is omitted, then the address of the server will be used instead.

The polling interval is how often the remote server will be checked.

Use Encryption is to use encrypted communications with the remote server. This is only applicable for 1.5.0 or later servers.

Finally, the New Projects option configures how the monitor will handle new projects on a server. There are two options: always show or always hide. When always show is selected, the projects will be automatically displayed in the monitor – otherwise they will not appear.

The final configuration option for a server is which projects to display. In the server configuration the user can set how projects are generally handled. To show/hide specific projects the user needs to select the projects. This is done by clicking on the “Projects” button on the Projects tab. This will list all the available projects for the server:

Any projects that have a check box next to them will be displayed, all other projects will be hidden.

Remember, to actually save and apply these settings, the “Ok” button in the settings dialog must be clicked.

End of Tutorial

And that’s it for configuring plug-ins and servers. The result of this tutorial is there will be projects displayed in the monitor:

Additionally, there will be an icon in the system tray that shows build notifications.

In my next tutorial, I will go over the information displayed in the monitor, plus show some more plug-ins. Stay tuned…

Introducing FastForward.NET

Some History

Near the end of year year, I started working on a CCTray replacement. This replacement had a different architecture, which were to overcome a number of design limitations in the original CCTray.

Basically, it was intended to cleaner, faster and easier to maintain.

Unfortunately, the project owner does not like redesigns, he thinks refactoring is a better approach. Thus my prototype went nowhere. And since it was not completed, it lacked a number of important piece of functionality.

Since then, we finally finished the 1.4.x releases and moved onto producing the 1.5.0 release (although this is still in progress). One of the major changes was in how clients communicated with the server. This changed from a method-call style interface, to a messaging-style interface. Along with this change we also wrote a communications client to simplify the communication between the client and the server.

After I modified the dashboard and CCTray to use the new client, I noticed we had a large amount of duplicated code – both between the two applications and within CCTray. Basically, each application and protocol had its own implementation. So, we have dashboard/HTTP, CCTray/.NET Remoting and CCTray/HTTP. It would be nice to move these all into one, so we don’t need to make three sets of changes!

So, I put together the Monitor API to simplify writing client applications. Then I started trying to modify CCTray to use it. And that’s as far as I got!

Both CCTray and the dashboard are complex under the hood. There are so many layers of indirection, that it is hard to trace what is happening. Add in that both clients are primarily project-focused (as opposed to server-focused) and I gave up after a while. Yes, it is doable, but I don’t like self-torture.

Welcome to a New Project

So, I returned to my old CCTray replacement. Since I know the project lead is not interested in a redevelop, I have moved this into its own open source project – so please welcome FastForward.NET.

I am intending that FastForward.NET will be a suite of client tools for working with CruiseControl.NET. These will not replace the heart of CruiseControl.NET, which is the server, but instead make it easier to work with. Initially, this project has only one tool – a monitor – but I have a few other ideas I am going to implement over time.

Under the hood, these tools will use the new Monitor and Communications APIs, so as CruiseControl.NET improves, the tools will be able to leverage the improvements easily. This has also been a good test-bed for ironing out issues with the APIs.

A Quick Tour

Unfortunately FastForward.NET isn’t quite ready for release yet, but I am hoping to have it ready within the next couple of weeks. But to get you interested, here are a few screenshots of what it will look like.

The main UI is similar to CCTray – it has the list of projects, plus a tree view containing the queues. Unlike CCTray, the tree view also contains the projects available:

There are a few major differences on this view. First, the monitor has a toolbar across the top as well as a menu. These have all of the commands for interacting with projects and servers. There are also context menus for various areas (not shown).

Next, the projects can be grouped by server. This grouping enables a user to quickly see which server the project is from. Both the server grouping and the monitor explorer can be turned off:

These settings are persisted, so closing and reopening the monitor will be the same as last time it was viewed.

The final major difference is two new tabs have been added. The first tabs shows the status of all the queues:

While the second shows all the current and pending build requests (i.e. what are on the queues):

As well has the main displays, the monitor also has a number of pop-up windows. These windows are generally project specific information.

For example, it is possible to see the current build status:

This is very similar to the CCTray version, but it does have a couple of differences. The current item status is displayed on the left hand side, and this time it does show the status. The details have also been grouped together and an elapsed time add.

There is also the packages list:

Again, this is similar to CCTray. The main difference is CCTray only allowed the user to select the download folder, monitor allows both the folder and file name.

Web pages can also be viewed, but this time they are contained within their own window:

It is still possible to view the web pages in an external browser – this is done by clicking on the little globe on the toolbar.

Finally, and this is new to the monitor, it is possible to view build reports from within the monitor. This will bring up the full history of the builds:

Clicking on a build will bring up the build report. This is a different build report from the dashboard, although it does contain a lot of the same details.

Additionally, it is possible to add custom build reports to this viewer. For example, here is a MSBuild log in the viewer:

Additional reports can be added as desired, similar to the dashboard.

The final screenshot I have is of the configuration settings:

This has been simplified from CCTray. The servers tab allows a user to add and remove servers, instead of projects. By default, when a new server is added, all the projects will be displayed. The actual projects for a server can be selected by clicking on the projects button, so similar functionality to CCTray is available.

Additionally, a number of tabs have been removed (e.g. notifications, speech, etc.) This functionality will be available under the plug-ins tab.

Rounding out the tabs, there are the templates and settings tabs. The templates tab allows a user to add new templates, which will be used in the build viewer. These are just XSL-T files, so it is reasonably easy to build new ones. The settings tab contains general settings for the monitor, e.g. show in task bar, start-up mode, etc.

I haven’t shown these tabs, as I haven’t quite finished them yet, but they will be ready for the first release!

The End, For Now…

So, that’s what I have been working on. I still have a little bit of tidying up to do before it is ready for release, but it won’t be too much longer.

Over the next few weeks, I write about how the monitor works, both internally and from a user’s view point. So, stay tuned, and let me know what you think…