October 29, 2004

Auto-Updating .NET Apps In LUA Situations

At work, I wrote the auto-updater for our primary line-of-business application. I made several assumptions about my requirements based off of the requirements of other software that we needed installed. I was able to assume Administrator rights on our boxen because of our mail client. We were using GroupWise 5.5, which required Administrator rights on the box in order to run.

We finally finished migrating to GroupWise 6.5, and now I have to rethink my assumptions. The new GroupWise 6.5 client runs on a limited user account quite nicely. So now I have to come up with an auto-update system that will allow our users to update our LOB app without requiring admin rights.

Here's what I've come up with so far. I'm creating a new launcher application and integrating the auto-update functionality into it. Here is my flow.

The installer places the entire application in the Program Files folder. When the program is first run, it looks at a registry key to check to see if a new version has been download. If a new version has not been downloaded and a new version is not available, then it runs the version that comes with the installer.

If a new version is available, it creates a new folder in the Local Application Settings folder to hold the new version. It then downloads each file from our web server and verifies the embedded digital signature in each file. If the file does not match, it throws an exception, pops up an error message, and launches the old version instead. If all files match, the new version registry key is set, and the executable for the new version is launched.

Prior to any executable launch, the executable is verified against the embedded digital signature. If the signature doesn't match, it throws an exception and pops up an error message instructing the user to contact the support department for help.

Once a new version has been in use for two weeks, the old version is deleted to make space. This way, if we need to roll back quickly, we can do so without putting too much of a load on our server. Usually, when we need to roll back, we know within one day.

Downsides of doing things this way: With the old way, we were able to push out required updates along with our software (.NET Framework 1.1 SP1, Managed DirectX, etc.). We can't this way because we can't assume that the new user will know the Administrator password, and I don't want to have a global user/password with admin rights hardcoded into our updater. We will have to use other means to push out the updates. Also, for shared workstations, multiple copies of our application will be resident on the machine (the original install plus a minimum of one update installation per user). We're currently at 10.6Mb, so this isn't too big of a hit.

I know that I'm missing something here. Anyone have an idea as to what it is?

No comments: