This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- It is not the component keypath - it is COM regisration
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 09, 2010
02:53 PM
Unwanted User Launch of Installer
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).
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).
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 12, 2010
07:46 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 13, 2010
01:11 PM
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 13, 2010
02:27 PM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 13, 2010
02:43 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 14, 2010
03:00 PM
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.
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.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)