5 replies to this topic

[vnadoda]

Hi,
I have created a package using ISWI 2.03 which install one exe.
It has file association say xyz. When another user (means anybody except who install application)try to open any file with that extension,Say (abc.xyz) it open up windows installer and try to re install that exe.
NOTE: Application is getting installed for ALL USERS.

Is there any means I can supress this behaviour of windows installer?

Any help will be greatly appreciated!!

Thanks in advance.
-Vipul

[hambone]

although MSI offers the ability to turn off the installer functions ( using the DiasbleMSI policy ) i know of no method to disable the auto-repair ( other then to eliminate the key-path information post-install ).

your options seem to be limited to remove the package information  from the MSI Registry Database on the system.  This in effect removes all msi control information regarding your package from the MSI Engine.  although this is not recommended it is sometimes necessary with nuisance packages...

[Stefan Krueger]

Actually I would recommend to fix your setup instead of disabling auto repair. Start by validating your package. Other helpful steps would be looking into the Event log of Windows, and globally enable installer logging (see http://www.msifaq.com in section Runtime Errors). This should tell you what the installer is trying to repair and should give you hints where you need to change your package.

[amacrobert]

I presume you are on W2K or XP. The event log will show you why the repair has kicked in. It will list the package/component that is being 'repaired'. Sometimes it happens when you don't use self-registration in your database on COM objects. I had a problem with Office 2K mscomctl.ocx and our application having a different level. Our msi would repair office and vice-versa. The hack was to rename the registry key for the product so that it was not found. The key is a \HKCR\Installer\Products\{your product guid}. Rename the key to something else. To fix this try using self-registration of dlls/ocxs in your project rather than using embedded registry keys.

Andrew MacRobert, Misys plc

[Ron Weldy]

Is it just me... but doesn't it seem that dll hell is being replaced by install hell?

[Ron Weldy]

But seriously now... I have just verified that I am having what appears to be the same problem as 'amacrobert' above. When you bring up a dialog in my application that has the date picker control, the windows installer will fire up and try to repair the application. In the log it says "Detection of product {<key>} feature '_MainFeature' failed during request for component {<key>}".

I don't think it was doing this until a recent build, so my thought is that somehow the merge module (mscommct2.msm) that I am using to install the control got updated by windows update or some other software service pack install I did on my development machine.

Anybody got any further input on how to track down, fix and avoid this problem in the future?