Friday, May 11, 2007

Auto Updates of Desktop Applications

I guess it's a sign of the times that the vast majority of customer facing software development I have done since leaving university has been ASP.Net web applications. For all the pitfalls of this environment what is great is the level at which you can update it live.

The Esendex Web/Email/API front end all runs from a web farm, so we have multiple servers feeding the same information through a load balancer. This means when we update we can safely remove a server from that array, update it, and put it back--and no one sees any downtime.

Recently though I've been delving into writing desktop applications for a project that I'm not at liberty to fully divulge at this moment in time. However, what I can say is that this application needs to be able to update itself in a number of ways.

This application gets its functionality primarily from plugins, which are loaded at runtime from a directory on the user's computer. This makes the "host" application relatively dumb, and I've spent a fair few hours getting these plugins loaded in an easy to manage way.

That is now all working and today I've managed to get a first pass at automatically updating the plugins. Well, I guess "automatic" is pushing it a little at this moment in time, but eventually the application will periodically ask for available updates and then go through the process which is currently being kicked off by a menu item click.

The main problem is that you can't update a file that is currently being used, which means the update procedure can't complete while the application is running. Applications like the Firefox browser appear to solve this by finalising the installation when the application restarts.

The current pass of the update manager works in this way, and I can't see a way around it at the moment. This is fine for the plugins that are being loaded--we can just finalise the update process of the plugins before we load them. The problem is, how do you update the main host application that is loading all the plugins?

It seems the only way is to create a second application which has the sole task of finalising updates, and then kicks off the main EXE that can be updated as part of the main updating process along with the plugins.

Of course, this raises the question of how do you update the "loader" application, but I guess if this app is simple enough that won't need to happen that much. Although, the main application could update the loader, as by the time that is running the loader should have quit.

An additional task of this updating process will also need to notify the end user of any new plugins that are available for their particular application. I think that this will have to be a separate process though, although it will probably use the same design patterns as what I've got at the moment.

The hurdle we need to get over though is that we won't have any control whatsoever over this install and update procedure, and that is quite a big hurdle. This is run of the mill stuff to those developers who write desktop apps day in day out, but as a service provider of online applications it's going to be a step into the unknown.

I've always been a subscriber to the "It Just Works" school of thought when it comes to software development, but that is easier to accomplish when you have full control over where it's running and how it's deployed. This desktop application needs to be able to hold its own across a variety of PC setups, and that will require a lot of testing before it's released.

I think I can recall only one instance of Esendex releasing a limited Beta to customers during my time here. This might have to be the second. :)

No comments: