MSI installer Update with Com interop

Question

I've created an installer (the basic windows installer type) some weeks ago (version 1.0.0) which deploys some dll's and also registers one of them for com-interop (with vdsrpCOM). Not a big deal actually. I also have an helper-class which does some things onBeforeInstall and onAfterInstall via custom actions (Extracting a ZIP-library in a specific location).

Now it's time to update my product, and more specific my com-registered dll. So, i changed the file and assembly version of all dll's that have to upgrade and mark the installer RemovePreviousVersions = true. Ofcourse, beside updating the file and assembly versions of my projects, i also update the version of my installer (to 1.1.1).

When Installing this new version, every dll that has a new file version gets nicely overwritten, and those that haven't got a changed fileversion aren't (ofcourse, MSI is that smart that 'If the thing isn't changed, why should I replace it then?'...)

The only error I encounter now is that my com-registered dll isn't registered very well anymore. I also notice that in ole-view, my dll is still registered but is missing some lines of code in the 'Registery section', more specific: MyNamespace.MyClass = MyNamespace.MyClass CLSID = {bla-bla-bla-bla-bla}

Uninstalling and reïnstalling solves the issue. But ofcourse, I don't want to unistall and reïnstall because that is what the MSI is supposed to take care for.

So, I've been thinking, as I do have an installerHelper which gets triggered on onBeforeInstall by a custom action, why don't I just check myself if there is a version installed and if so, remove it.

Now, the only constant between versions in the UpgradeCode. And there is where my question starts: How can I get the upgrade code from withing my helper class, check for previous versions that have the same upgrade code, UnInstall those ones in the onBeforeInstall method?

Or, maybe better, how could I ensure that com-registering is handled well on an update? (thats maybe even easier, but I sure like the Idea to be able to force a complete unistall/reinstall)

Answer 1

This is an example of why any form of "self registration" is not a best practice in a windows installer world. When you use built-in Windows Installer functionality it generally just works and you get proper transactional behavior (install, uninstall, rollback, commit ). When you go out of process and use "helpers" it gets ugly fast if you don't know exactly and I mean exactly what you are doing.

It's not clear to me if your COM server is native or managed. It's also not clear what tool you are using to author your MSI. The exact answer would depend on these two factors.

But in general, the concept is to "harvest" or "extract" the COM metadata from the DLL and author it directly into the MSI either using the COM tables (ProdID, Class et al tables ) or to avoid certain COM advertisement annoyances the Registry table. Tools like InstallShield have support to make this easier ( right click | COM Extract or COM Extract at Build = True or .NET Com Interop = True ) but there are also ways with tools to get this information and then import it manually into your installer project or code.

The advantage of doing it this way is that MSI completely understands the resources of that DLL and can manage it all for you. This improves installer performance and reliability.