Servicing Reg-Free COM Applications: Ideas?

No news, but so far so good on MMM.  No new release ready yet I'm afraid, and it may be late February 2009 before we see one.  Sorry.

For now: MMM 0.6.6 is still current.

Servicing XCopy Deployments

One of the issues we face when creating XCopy deployments with Registration-Free COM is a new challenge in servicing our applications.

Installing applications conventionally means that we use a great many components stored in central locations locatable via the registry.  It also means that Windows Update, downloaded Microsoft patches, etc. all update our applications as a matter of course when users install them.  Not so for our isolated components though.  We keep the old, possibly buggy, and possibly security vulnerability ridden copy of each component library.

This is even a problem for those of us using Reg-Free COM with Windows Installer to perform per-user installs that do not require elevation under Vista or Windows 7.  By the way, expect to hear more about per-user installs once Win7 hits the street.  Short term, consider that as of Win7 (Beta) Microsoft has a designated place for per-user installs now: a folder created under [LocalAppDataFolder]\Programs.

Now we could just periodically repackage and redistribute, hoping users will redeploy.  But is there a better method?  Maybe something that doesn't end up overlaying data files (settings, etc.) that may have changed with usage since the user first unzipped our package?  How do we help the users track versioning unless we replace the EXE with a new one as well, even if only upgrading libraries?

I don't have a general answer to this yet myself.

For XCopy installed applications I'm considering using a small, separate INI-like version.inf file that my Help|About... dialogs reference.  Maybe with nothing but the actual EXE version numbers and a letter suffix for such servicing updates that only upgrade components.  Probably distributed as a smart self-extracting archive that extracts to a temp folder then runs a small utility from temp to ask for the location to update, and then just replaces the impacted libraries and version.inf file itself.

Per-user MSIs can probably use regular Installer patching, but I need to review the caveats again.  They still require individual updating though because they don't use the system copies of libraries that do not come with Windows (the VB 6.0 Extended Runtime Files for example - i.e. the controls bundled with VB6).

Any better ideas?

KB 926857 and KB 957924

This came to mind because of the December 9, 2008 critical security update Microsoft put out.  I won't offer a link (KB 926857) because this Update patch was horribly buggy, installing several faulty controls (version 6.0.98.12).  It was replaced by KB 957924 December 30, 2008 (version 6.0.98.13 controls)* which may be better.

* I have not personally evaluated the new Update yet.

• Posted at Monday, January 19, 2009 08:57 AM
• In General Category | Permalink