The Catch-All Component

One of the fundamental problems inherent in all packaging tools which use snapshotting to produce an MSI package, e.g. Wise Package Studio, MSI Studio Pro, AdminStudio, etc, is its inability to associate registry entries with their respective components.  The result is packages where COM registration data that hasn't been moved to their respective advertising tables (ProgId, Class, TypeLib, etc), and may leave behind several (hundreds) entries in the "Catch-All" component.

This problem is further compounded when common run-time files (such as MsComctl.ocx, ComDlg32.ocx, etc) are replaced with merge modules, which leave behind several orphaned COM registration data in the Registry table - thus leaving no longer having the original file to correctly reference.

I feel that this is something that these package authoring vendors need to address, especially with major vendors like Flexera, who's Repackager utility has largely been unchanged for several versions of AdminStudio.

That is why I have been working on my own tool which addresses this oversight.  Now that Visual Studio 2012 Pro is free, I've had some time to invest in developing a tool to remediate entries in the catch-all component.





The idea is that all COM information will correctly be aligned to their respective components, orphaned registry entries will be deleted, and duplicate registry entries that result due to the inclusion of merge modules will be deleted.

This has a big flow-on effect on your packaging workflow.  Automating this in this fashion can result in a massive amount of time savings, which in turn will increase the quality of your snapshotted packages.  This will then allow you to effectively manage your components, and significantly reduce effort required to do conflict management against your portfolio of application packages.  This ultimately means lower support costs, and the assurance that what you're deploying to your organisation will not cause "DLL Hell".

Comments

  1. Good post. Something I always try and clean up manually even though most packagers I've known either don't realise or care! Would be interested in giving the tool a whirl if it's available.

    I typically avoid merge modules these days, all the VB6 ones in AdminStudio are well out of date for example, so using them can replace your up to date versions with ancient ones. I just set the components to shared/permanent for dll/ocx in the System folders to avoid issues on uninstall.

    ReplyDelete
    Replies
    1. Hi Dan.

      The tool half worked, but it had a lot of bugs (like failure to handle 64-bit MSIs properly). I'll concede that it is because I am too much of an amateur programmer, and unfortunately life (work, wife and two kids later) just got in the way for me to spend time fixing it.

      I can post the source code on Github, if you're interested. Perhaps, you'll get further with it than I ever did, but you'll probably look at the spaghetti code and run the other way. :)

      Delete

Post a Comment

Popular posts from this blog

AppUserModelID & Disappearing Shortcuts in Windows 8

Sideloading Universal Windows Apps on Windows 10 (Deep Dive)

An alternative method of installing device drivers