Register COM Interop Dlls with WISE

Question

The application I'm talking about consists of vb6 (80%) and c#, .Net Framework 4.0 (20%). All new components are created with c#. With Microsoft Interop Forms Toolkit 2.1 we create the COM UserControls that we later embed in vb6. For Forms we use normal classes to create and open in vb6 (COM Visible project). To create the setup we use wise.

Locally everything works fine - The problems only occur when we install the application on a non-developer machine with the wise created setup.

We added a class to open a c# Form to an existing interop toolkit project. It works fine on the developer machine and also when we make a new installation on a pc(non-dev-machine). The new class is just used to open the form.

But when we update our application to a newer version, that class is not working anymore. We have to uninstall the old version and install the new version to make it work again.

Anyone had a similar problems before?

I'm grateful for any advice

Answer 1

This seems like it is an issue with Windows Installer and the sequencing during the upgrade. Does your application allow side by side installs (e.g. Version 1 and Version 2 can be installed at the same time) or does your installer upgrade earlier versions to the latest version? You might try logging the installation and reviewing the log file to see exactly what is happening during the install / upgrade process.

You can log an msi installation by invoking Msiexec from a command line.

This may provide greater insight and help focus your efforts to debugging the problem.

Edit

From what you've described it seems that on fresh installation the install works as expected. When you upgrade earlier versions it would seem that the COM Interop components are not registered properly. This could be an indication that the sequence of events is a little off with regards to when the components are copied to the machine and registered vs. when the existing product is removed. While not exactly identical, see this SO Question and answer for more details. Also, have a look at the RemoveExistingProducts action in Windows Installer for more information.

I would log an installation that you know works without issue (e.g. on a "clean" machine) and then log an installation that you know will fail (e.g. an upgrade) and then compare the two log files using a tool to see if the output is identical. If not, that gives you a clue as to where to look. If they are identical it might be time to engage with the vendor and see if they can assist with determining what's causing the issue.