UAB implemenation questions

Topics: Updater Application Block
May 31, 2006 at 12:42 AM
originally posted by: Mike_Liddell

I'm putting together my first UAB rich-client application and I have been investigating a few approaches. I wanted to air some thoughts and see if there are any comments or suggestions. Any ideas appreciated

My main requirements are:
1. handle a large number of post-install actions, including config updates, stopping/starting services, creating local user accounts (for the services) etc.
2. initial installation and final uninstall of product is via MSI, eg from CD
3. I prefer if the auto-update stub is updatable too, ie all the interesting code is in the application itself.

Issues with post-install actions
the post -install actions have to happen both a)post-MSI-install and b)post-update. Putting the logic directly in ActivationProcess's wont work for (a), so I'm planning to put all the logic at the start of the application, eg if(firstRun) ... so that it is consolidated and easy to work with. The main alternative is Installer classes and an installutil call from the MSI and the manifests, but the on-first-run approach seems cleaner to me at the moment.

Issues with Manifest IDs vs version numbers
The base logic to determine which manifests to apply is "any manifest not listed in the special applications folder". The manifests might be aligned with an application version number but the app has no intrisic knowledge of the manifest IDs. I don't want to deploy the current version only to have an update immediately applied (esp as I am planning to do one-folder-per-version). My current solution is to put the app-version-number in the Manifest Description field and only perform updates on manifests with an version number higher than the current application version. Application version will be a app.config setting, although it will be in-line with all/most assembly version numbers.

Issues with update-in-place
I'm not a big fan of the WaitForApplicationExitProcessor and attaching to the various threads complicates debugging. I think I prefer a one-folder-per-app-version approach and a tiny shim that selects the highest version number folder. Also, this allows easier rollback to last known working configuration and avoids the locked file problem. The main drawbacks are config-migration and cluttering up the Program Files\App\ folder. I would be interested to know how people are finding update-in-place when complex actions are involved. Also, are people still doing the one folder per version?

Issues with File download, manifest bloat, IIS6
To avoid listing every file in the manifest and adding numerous file extensions to IIS, I deploy a zip file and I have an IActivationProcess that performs the unzip. Also, I find debugging a BITS job with multiple files to be a pain.. the error messages never indicate the file in error.

So anyway.. this is really a call for comments. I have a prototype that does the above and I'm generally happy with it. But there are probably a number of alternatives I haven't thought of yet.