.NET Application Updater Component

For those who are writing Java application, you can use Java WebStart to create rich client which allows automatic update of the application. The equivalent of this for .Net Framework is called .NET Application Updater Component.

Details of the component can be found here.

Prior to .Net all deployment needs to update registry, the following articles talk about simplifying the deployment. In fact, you can use both concepts together.

I tried the Application Updater and found it to be very easy with one caution:

Don't use DownloadOnDetection. I found that when you do that it keeps detecting and downloading the code even if I did not change the application version.

I used Method 3 for the deployment and it works well with our users. Here is a snippet describing it.

The final approach used to perform the application update was inspired by the side-by-side assembly model of the .NET Framework. Instead of trying to update the application itself, create a new upto-date version of the application next to the existing version. The new version can be created by merging the existing application directory with the downloaded update. When the new version is complete, the user will automatically use that version the next time they launch the application. The original copy of the application can then be removed. This tricky part is figuring out which version to launch at any given time. To do that, a program named Appstart is introduced. Appstart is the entry point into your application. With this model, your application directory will look something like this:

Program Files

MyApp

Appstart.exe

Appstart.config

V1 Folder

MyApp.exe

V1.1 Folder

MyApp.exe

To run your application, you always run Appstart.exe. If you want a shortcut on the desktop, the shortcut should point at Appstart, not at the application directly (Note that you can rename AppStart.exe to be whatever you want, ex. YourApp.exe). Appstart.exe is a very simple program that reads the Appstart.config file and launches the specified application. A valid Appstart.config file looks like the following:

<Config>

<AppFolderName>V1 Folder</AppFolderName>

<AppExeName>MyApp.exe</AppExeName>

<AppLaunchMode>appdomain</AppLaunchMode>

</Config>

• Whenever the user starts using the program, it will go to the webserver to see if there is a new version of my application. If there is, it will download and then he will start using the new version.
  
• My application contains multiple assemblies (.dll files). If the user deletes them, the updater component will automatically get a new copy from the webserver.

I found the easiest way to deploy it is to first go to the users workstation to set it up. This is because I want to make sure the user launches the application from the launcher and not the assembly (.exe file) directly so that the updater will work. The application needs to be launched through the AppStart.exe. (Just as you use JavaWebStart to start your Java Web Start applications).

Application Scheduling

Sometimes it is necessary to perform activities on regular intervals such as:

1. Sending daily email alert.
2. Compiling wip @ a specific time.
3. Compiling yield or transactions either shiftly or daily.

This can be easily done by writing a console (non GUI) application and then scheduling the application to run at regular intervals. With Windows 2000, Windows XP, and Windows 2003, you can use the Windows scheduler.

The Windows scheduler was first introduced in Windows NT but it did not provide a nice interface for adding to and viewing the schedule (using AT command - similar to the command available in Unix). This has since been improved.

Nice thing about the Windows Scheduler is you can set it to run as different users. Typically, most will run under Admin account. However, note that when it runs, the screen will only display in the console.

One of the benefit, Windows Scheduler has over the Unix (cronjob) is that it has a built-in mechanism that will ensure only a copy of the schedule item will run at any time. While Unix does not do that. For example, you may schedule extractData and schedule it to run every 3 minutes. In Unix, if the extract takes more than 3 minutes, you may end up with multiple copies running at the same time. This will not happen if scheduled in Window scheduler.

There are also some failsafe such as automatically abort if the job takes more than a specified amount of time.

Finally when we schedule a job we typically expect it to run automatically. There are some additional precaution we should take:

• have a log file output so that we can trace when there are problems. Easiest way is to redirect the output of the program (for example extractData >> c:\log\extractData.log)
• Have the application generate a heartbeat file each time it completes successfully and then have another program monitor the heartbeat file modified time. If the heartbeat update time exceeds a threshold, just have the application send an alert.
  

Interface Matters

One of the key things in programming is the interface. This is how the user interacts with our application. Take example of some of the programs we used to use. In word processing, we had WordStar, then WordPerfect and now Microsoft Word.

Why did Wordstar die off, it is due to the interface? WordPerfect was more intuitive than Wordstar. WordPerfect provided the first WYSIWYG. Then MS Word came along and provide an even more intuitive interface.

Another example is Lotus 1-2-3 again killed off by an application providing a more intuitive interface - namely Excel.

Word of caution though, intuition is very subjective and familiarity comes into play also. For example in some applications like web sites, there are certain expectations like the menu is on the top or side. So we have also got to take into consideration user expectation. Another example is when we drive a car, we expect a steering wheel and not a joystick.

Two years ago, I attended Lotusphere and one of the session covered was "Interface Matters". Go to the website. Even though they use Lotus Domino as a platform, some of the ideas covered can be used in any other platform.

Think of interface as packaging for your software. You can see some fantastic ideas out there such as Ipod, Macintosh. Elegance and simplicity is the key to a successful interface. Interface designing is an art as well as a science so have fun with it but make sure to get feedback from your users!!