Unwanted User Launch of Installer

[Peter_Kosenko]

I am baffled. An installer that used to work correctly now starts up automatically (and unwantedly) from user profiles after it is installed for All Users. None of the components is "advertised," all registration has been made, and all the files seem to have already been installed under an All User installation.

The feature involved has a small applet packaged as an object attached to a feature. It also contains a couple merge modules of common DLLs attached. And a menu shortcut.

But I can see nothing amiss with any of that.

So what is it that causes installers to launch from user profiles even if they seem to have been installed for All Users already?

Or just what is it that causes installers to launch automatically from user profiles in any case? . . .

So that I can try to track this down.

The problem is that when run as a restricted user, the installer complains about being unable to re-register HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINES keys (which is expected). But as far as I can tell, nothing is wrong with the application. It runs fine after the various registration failures of the user run of the installer (i.e., it is already registered).

***********

I have notices a few things. Under the Product Key in the registry, the "Usage" key lists the Feature that is causing the problem. But under the Features key, the feature is listed as installed. What is "Usage" anyway? Another one of those things that Microsoft doesn't bother to explain, and that isn't in the Installer help. Taking this "Usage" reference to the Feature out of the registry does not cause any change in behavior (I still get the unwanted user launch).

What is "Usage" anyway?

I also noticed that the "ShowCmd" field of the shortcut table for the shortcut to the applet EXE is null while all other shortcuts are "1". But this doesn't seem to be significant. The field look like it controls how the EXE dialog shows (SHOW_NORMAL, say).

[DebbieL]

Does the Event Viewer give you any clues about what's going on? It might list components that Windows Installer thinks need to be repaired when the installer starts back up automatically.

[Peter_Kosenko]

Yes, thank you. Inspecting the view log indicated that the component I suspected was causing the problem was causing the problem:

Detection of product '{41CB22A8-FBFF-46A7-AAC9-BEA5BF16DB53}', feature 'SEERMetrics' failed during request for component '{5760F738-3DBC-4D59-AB58-E06F16E3013D}'

The {5760F738-3DBC-4D59-AB58-E06F16E3013D} component is a ChartFX DLL in a merge module that is consumed into the main installer. ChartFX is graphic charting DLL we just introduced into two of our products.

Unlike Crystal Reports, SoftwareFX does not prepackage its products as merge modules, so, if we were going to use the ChartFX DLL in more than one of our products, I had to create a merge module of it myself.

It is a COM DLL, with a TON of COM registration that imports into the merge module. I may have to check whether there isn't some issue in the registration between registering the DLL with regsvr32 and registering it with the InstallShield COM registration import? Ugh!

But maybe I am misreading the error message. I do not know why "detection" of the "SEERMetrics" feature should fail, since it is installed and registered as installed in the "Features" hive of the product key. But I admit that there is some complicated programming going on. The feature is selectable in the installer. So maybe what I need to do is test the feature state (maybe it was changed by the installer?).

But my real question is why should REPAIR kick in in the FIRST PLACE without my having chosen to RUN the installer? Does MSI just automatically run for all users, or can you suppress that? If the installer was already installed for ALL USERS, why should it be necessary for MSI to run it again?

[DebbieL]

The following MSDN page offers some background on why Windows Installer is probably trying to repair the specified component:
http://msdn.microsoft.com/en-us/library/aa371546(VS.85).aspx

Here are some other explanations that might be helpful:
http://blogs.msdn.com/astebner/archive/2005/01/13/352649.aspx
http://www.msifaq.com/a/1037.htm

[Peter_Kosenko]

Yes, thank you very much. The first link looks very promising in my hunt for the bug. It is running from the shortcut that causes the installer to automatically kick in and try to repair. I'll get back if and when I fix the issue.

[Peter_Kosenko]

I checked the file KeyPath for the ChartFX.ClientServer.Core.dll in the merge module that I created. That did NOT seem to be the case. It was there, and the reference was okay where occured elsewhere:

chartfx.clientserver.277A518E_FC0A_4783_96C5_FB40A0F66220

The problem seems to be that COM import did not do a complete job with this DLL. There are tons (I mean nearly a hundred) registration entries for this DLL.

I installed and then tried to run the feature (SEERMetrics applet) from the shortcut. I got errors.

I installed and then ran RegSVR32 on the ChartFX.ClientServer.Core.dll and got NO errors when I inovked the applet from the shortcut.

I recompiled the merge module with "Self_Registration" checked on the DLL. It was not previously checked. That solved the problem.

Of course, that makes all of the "COM import" stuff completely irrelevant (might as well leave it out, since it doesn't work). It also defeats the supposed "best practice" of having the installer do all the registration.

This is another case where there are in fact no registration specifications for the DLL other than the manufacturer's assumption that you will run self-registration or regsvr32 on it. And there is no manufacturer's merge module (which would have implemented ALL the registration, supposedly).

Basically, you are up a creek if you have to create a merge module for SoftwareFX's ChartFX.ClientServer.Core.dll unless you use the "Self-Registration" option.